Seumas Soltysik <ssoltysi_at_aurea.com> writes:
> I am still a bit confused about the difference between --steal-lock and
> --disable-locking. I understand that --steal-lock basically deletes/steals
> the lock property on revision 0 which controls who has the right to perform
> an svnsync. I use this in the event that a network issue interrupts a sync.
> Is --disable-locking basically a super-set of this? I have seen by trial
> and error that --steal-lock and --disable-locking are mutually exclusive so
> I am assuming that --disable-locking does the same thing as --steal-lock
> plus more.
svnsync locks the destination repository by setting a revision property
on r0. This ensures that only one svnsync process runs and writes to
the repository. If an svnsync process terminates abnormally it may
leave a 'stale' lock that prevents other svnsync processes running.
--steal-lock causes svnserve to take over the lock that was created by
some other svnserve process. It is used when a 'stale' lock is present
and would generally only be used after manual verification that the
previous svnsync was not running.
--disable-locking causes svnserve to ignore any existing lock and also
to not set a lock. It is generally only used when some external
locking, such as the lockfile(1) command, controls when svnsync is run.
One reason to use external locking is that before Subversion 1.7 the
revision property was not properly atomic and so the lock could not
guarantee exclusion for processes started in quick succession.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-09-24 14:32:13 CEST