Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 0 down vote accepted

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).

share|improve this answer
    
Well, one issue is that dump->filter->load requires shell access to the original repository. Also, svndumpfilter (as well as svndumpfilter3) choked on a copy-from revision in the repo. The initial svnsync is running now, so I don't know yet if svnsync will cope with that revision, but I'd assume it for now. –  Palmin Nov 29 '10 at 19:03

Since I had to tweak the directories within the target repository a bit, here's what I ended up doing (the old repo had a path prefix of /SOME/DIR/ which I wanted to get rid of):

  • Initialize and synchronize: svnsync init [new repo URL] [old repo URL]
  • svnsync sync [new repo URL]
  • Dump new repository for filtering: svnadmin dump [new repo PATH] >REPO.dump
  • Remove prefix /SOME/DIR from repository paths: svndumptool.py merge -i REPO.dump -s '^SOME\/DIR\/' '' -x SOME -x SOME/DIR -o REPO_filtered.dump
  • Reimport repository: mv [new repo PATH] [away]
  • svnadmin create [new repo PATH]
  • svnadmin load --force-uuid [new repo PATH] <REPO_filtered.dump
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.