-
Notifications
You must be signed in to change notification settings - Fork 14
/
.autosync-example
113 lines (105 loc) · 5.29 KB
/
.autosync-example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
[autosync]
path = ~/amw
# If pidfile is not explicitly specified, the name of the used config file
# will be appended with '.pid', e.g. for a config file ~/.autosync, the PID
# will be written to ~/.autosync.pid. This option allows to override the
# default.
#pidfile = ~/.autosync.pid
# Available synchronization methods: "xmpp" and "none", "autosync-server"
# may be implemented later (to potentially be interoperable with SparkleShare).
# If xmpp is set as synchronization method, a config section [xmpp] with at
# least two config variables username and password must exist, otherwise
# dvcs-autosync will fail to start.
#syncmethod = none
#syncmethod = autosync-server
syncmethod = xmpp
# Available notification methods: "desktop", "xmpp", "all", and "none".
# Default if not specified is "desktop" and indicates that KDE/Gnome/notify
# notifications (typically in the tray area) should be used to inform the user
# when anything noticable happens. "none" disables notifications altogether
# and "xmpp" causes notifications to be sent via XMPP to the account specified
# in the "alsonotify" option in section [xmpp]. "all" will send notifications
# to both desktop and xmpp.
notifymethod = all
# There are currently two options for handling file notifications, as neither
# one is perfect. You can choose between the 'conservative' option, which is
# slower but should work in every corner case, and the 'optimized' option,
# which will consume less CPU and I/O resources on a remotely-triggered pull,
# but may miss local changes until the next time autosync is restarted or a
# manual commit is done on the repository.
#
# The problem is that during a pull from the remote repository, changes will
# be applied to the local file system and consequently generate file-changed
# events. These events are in turn translated to add/remove/move commands for
# the DVCS, which would duplicate the remote changes locally in the history and
# obviously doesn't work e.g. for file removes. Therefore, the file/dir changes
# caused by a remote pull must not be translated to local DVCS changes.
# The conservative strategy solves this problem by completely suspending event
# handling while the pull is active. Because it is possible that _real_ local
# changes occur concurrently to the pull, the startup command will be run after
# the pull has been finished and event processing was resumed again. This is a
# safe option, as all local changes that occurred before or during the pull
# will be picked up by the DVCS client. However, when no local changes occurred
# (which is more probable), then this strategy causes unnecessary I/O overhead.
#
# The optimized strategy also suspends the execution of local DVCS actions
# triggered by file/directory events during the pull, but does not completely
# discard them. Instead, all events that occurred during the pull are recorded
# in an event queue which is replayed after the pull has finished. The
# advantage is that a complete re-scan of the local repository is avoided and
# only those files/directories that saw some modification are re-checked for
# local changes. The disadvantage is that this depends more strongly on the
# change detection capabilities (trivial ones done by autosync-dvcs and more
# complex ones done by the respective DVCS client) and it is therefore not
# guaranteed that all local, concurrent changes are being detected. This option
# is still being evaluated for corner cases where it doesn't work, and
# therefore is not yet the default strategy.
pulllock = conservative
#pulllock = optimized
# The number of seconds to wait for additional events before acting. Setting
# this lower will increase the synchronization speed at the cost of CPU and
# transfer resources.
readfrequency = 5
ignorepath = .git .svn .hg src/packages src/java/openuat
src/csharp/sparkleshare src/cpp/cross/keepassx src/android/ipv6config
# Note: addcmd, rmcmd, and modifycmd take one argument, movecmd takes two (first the source, then the destination).
# Note: statuscmd should return with code 0 when nothing has changed in the
# local checked-out tree that needs to be committed and non-zero when a commit
# is required.
# Note: commitcmd also takes one argument, which will be substituted by a generated commit message.
[dvcs]
# for git
statuscmd = git status | grep -iq "nothing to commit"
addcmd = git add %s
rmcmd = git rm -r %s
modifycmd = git add %s
# doesn't work when the source file no longer exists, git expects to move it itself
#movecmd = git mv %s %s
# use this instead, git will figure out that it was a move because the file is similar
movecmd = git rm %s
git add %s
startupcmd = git add -A
commitcmd = git commit -m %s
pushcmd = git push
pullcmd = git pull
remoteurlcmd = git config --get remote.origin.url
# for mercurial
# next line works with bash as shell, returning 0 if nothing has changed
#statuscmd = test "`hg status`" = ""
#addcmd = hg add
#rmcmd = hg remove
#modifycmd =
#movecmd = hg mv %s %s
#startupcmd = hg addremove
#commitcmd = hg commit -m %s
#pushcmd = hg push
#pullcmd = hg pull -u
#remoteurlcmd = hg showconfig paths.default
[xmpp]
username = your XMPP id here
password = your XMPP password here
alsonotify = if set, another XMPP id that will get notified when something happens
[autosync-server]
server = http://whatever.sync.server
username = your-username
password = your-password