Subversion repository maintenance
Upgrade to Subversion 1.7
I recently upgraded to Subversion 1.7 (if for no other reason than to keep up to date). I use VisualSVN (2.5.1), and the upgrade was seamless and painless – literally nothing more than running the installer (msi). At the same time I upgraded TortoiseSvn (1.7.1.xxx), and it too was seamless. The only thing I needed to do was upgrade my working copies of code under svn control.
Maintenance
Once I had completed this upgrade without pain, I decided to re-organise my repositories. My current repository structure looked similar to
tags
branches
trunk
clientA
projectA1
projectA2
clientB
projectB1
projectB2
clientC
projectC1
projectC2
Now this is fine, except for the fact that over the years, it has gotten quite big. Additionally there is just something awkward about creating a tag “clientA-release” which will include clientB and clientC projects (apart from probably being a bad practice). It was clearly time for a split.
svnadmin dump %REPO_PATH%/repos > repos.dump svnadmin dump %REPO_PATH%/repos -r162:178 > repos-162.dump
This will dump the entire repository in text format (with embedded binary) – which we will use later on. If nothing else it serves as a backup, albeit a rather large one. The first command will dump the entire repository, while the second one will only dump changes from revision 162 to 178. Be warned – this can take quite a while, so don’t start with it unless you have time to waste.
svndumpfilter --renumber-revs include /trunk/clientA /tags/clientA < repos.dump > clientA.dump svndumpfilter --renumber-revs include /trunk/clientB /tags/clientB < repos.dump > clientB.dump
This will read from the dumpfile created in the previous step, and write only that specified in the “include” parameter.
- Remember to specify tags and branches as well
- There is also an “exclude” parameter available
- I liked the “renumber_revs” option, that renumbers the revisions for this particular client, removing any revisions applicable to other code
sed.exe -b s/path:.trunk\/clientA/path:\x20trunk/g clientA.dump > clientA.mod.dump sed.exe -b s/path:.trunk\/clientB/path:\x20trunk/g clientB.dump > clientB.mod.dump
At this point you may choose to modify your dumpfile, although please be aware it is very easy to mess it up – please create backups of it. In your new “clientA” repository you will probably not want the root folder “clientA” – as it was in your original repository. You must modify “trunk/clientA” to become “trunk” – in other words move everything up a level. Problems I encountered include the following :-
- My favourite editor Notepad++ had a ceiling as to the maximum size dumpfile it could accommodate
- Other editors that could handle large files e.g. ConTEXT messed up CR and LF special characters, rendering the dumpfile useless. I’m not saying ConTEXT is bad – I probably just wasn’t using it properly
- WinVI worked fine for me, but was just really slow to open, modify and save large files
- Be careful of just modifying “trunk/clientA” to become “trunk” – this combination may be in the content of a file e.g. batch file, or document, and will then cause the job to fail with inconsistent checkdigit counts. This is why I chose to replace “path: trunk/clientA” with “path: trunk”
- Gnuwin SED was my solution – a commandline utility that worked really well, and quickly too – this is used in the scriptlet above
svnadmin create clientA svnadmin load --ignore-uuid clientA < clientA.dump svnadmin create clientB svnadmin load --ignore-uuid clientB < clientB.dump
This will create a new respositories “clientA” and “clientB” and load them from the dumpfiles, including trunk, all tags and branches, with neatly re-ordered revision numbers.
Voila!
Powered by Zoundry Raven
