Version Control with Subversion - Login

Repository AdministrationCopied properties for revision 23406.Transmitting file data .Committed revision 23407.Copied properties for revision 23407.Transmitting file data ....Committed revision 23408.Copied properties for revision 23408.$Of particular interest here is that for each mirrored revision, there is first a commit of thatrevision to the target repository, and then property changes follow. This is because the initialcommit is performed by (and attributed to) the user syncuser, and it is datestampedwith the time as of that revision's creation. Also, Subversion's underlying repository accessinterfaces don't provide a mechanism for setting arbitrary revision properties as part of acommit. So svnsync follows up with an immediate series of property modifications thatcopy into the target repository all the revision properties found for that revision in thesource repository. This also has the effect of fixing the author and datestamp of the revisionto match that of the source repository.Also noteworthy is that svnsync performs careful bookkeeping that allows it to be safelyinterrupted and restarted without ruining the integrity of the mirrored data. If a networkglitch occurs while mirroring a repository, simply repeat the svnsync synchronize command,and it will happily pick up right where it left off. In fact, as new revisions appear inthe source repository, this is exactly what you to do to keep your mirror up to date.svnsync Bookkeepingsvnsync needs to be able to set and modify revision properties on the mirror repositorybecause those properties are part of the data it is tasked with mirroring. As thoseproperties change in the source repository, those changes need to be reflected in themirror repository, too. But svnsync also uses a set of custom revision properties—storedin revision 0 of the mirror repository—for its own internal bookkeeping.These properties contain information such as the URL and UUID of the source repository,plus some additional state-tracking information.One of those pieces of state-tracking information is a flag that essentially just means“there's a synchronization in progress right now.” This is used to prevent multiplesvnsync processes from colliding with each other while trying to mirror data to thesame destination repository. Now, generally you won't need to pay any attentionwhatsoever to any of these special properties (all of which begin with the prefixsvn:sync-). Occasionally, though, if a synchronization fails unexpectedly, Subversionnever has a chance to remove this particular state flag. This causes all futuresynchronization attempts to fail because it appears that a synchronization is still inprogress when, in fact, none is. Fortunately, recovering from this situation is assimple as removing the svn:sync-lock property which serves as this flag from revision0 of the mirror repository:$ svn propdel --revprop -r0 svn:sync-lock http://svn.example.com/svn-mirrorproperty 'svn:sync-lock' deleted from repository revision 0$That svnsync stores the source repository URL in a bookkeeping property on themirror repository is the reason why you have to specify that URL only once, duringsvnsync init. Future synchronization operations against that mirror simply consultthe special svn:sync-from-url property stored on the mirror itself to know whereto synchronize from. This value is used literally by the synchronization process,though. So while from within CollabNet's network you can perhaps access our examplesource URL as http://svn/repos/svn (because that first svn magicallygets .collab.net appended to it by DNS voodoo), if you later need to update that150