Svn – Is it safe to use svnsync for one-time conversion of a repository

svn

I have the task of extracting a subdirectory of a subversion (1.6) repository and place it into a new repository of its own.

For several reasons I wanted to use svnsync to replicate the subdirectory into a new repository. I now want to make sure that this is safe, because the SVNBook says (subversion 1.5)

svnsync is very sensitive to changes made in the mirror repository that weren't made as part of a mirroring operation. To prevent this from happening, it's best if the svnsync process is the only process permitted to modify the mirror repository.

and (subversion 1.6)

Warning

Do not modify a mirror repository in such a way as to cause its version history to deviate from that of the repository it mirrors. The only commits and revision property modifications that ever occur on that mirror repository should be those performed by the svnsync tool.

I am assuming that this is valid if you want to use svnsync to actually keep a mirror up-to-date.

Our use-case is

  1. svnsync a subdirectory of repository A to repository B
  2. Make subdirectory of repository A read-only (only for archival purposes)
  3. Make all further commits of the content on repository B

Can anyone confirm that this use-case is feasible?

Best Answer

In this position, I would always prefer to use the dump->filter->load method for this kind of task, as it's the cleanest route. (though I realise it's quite time consuming on large repositories). Is there anything that precludes this in your case?

That said, you will end up with a full, functioning repository after the sync, so it should work. For a clean break, run the following against your mirror repo after the first sync:

svnlook pl -v --revprop -r0 <path to repo root>

You'll see three svn:sync... properties that are created by the svnsync init command. I'd recommend deleting them before you make it writeable. I don't think this is absolutely necessary, but it should prevent mishaps (such as trying to re-sync after the two repositories have gone their separate ways.)

I'd still push dump->filter->load as the correct route, though... (Oh, and tag the old subdirectory and then delete it from the head).

Related Topic