Oh, so source code for that project I’m working on has been moved from CVS to SVN? Great, thanks for not telling me earlier so I could make sure all my changes were committed first.
Well it is about time we got rid of CVS. But isn’t moving to SVN a bit anachronistic given we have Git and Mercurial (and even Bazaar) nowadays, ready and willing to fulfill all our deepest, darkest version control needs? Isn’t SVN a bit…2002, as opposed to 2012?
No I am not being a smartarse. Just saying, is all. If I was being a smartarse I’d say that SVN is only an improvement to CVS in the same way being poked with a less pointy stick is better than being poked with a really pointy stick, but ideally I’d rather just not be poked by anything.
Oh, so eventually all the projects are going to move to SVN, but we can’t just yet? Because a large legacy project with decades of history was just imported into the one central SVN repository and it blew out the disk usage? So we now have to get a new machine to act as the SVN server?
You realise that with Git or Mercurial, you can pretty much put the repositores just about anywhere, and even move them around pretty much at will? Or even use one of the cloud hosting services?
No I am not being a smartarse. Just saying, is all. If I was being a smartarse I might make some kind of tortured analogy, comparing the switch from CVS to SVN to turning up to a gunfight with a butter knife, sneaking away to a weapons store, walking down the back past racks with all manner of handguns and automated weaponry, selecting a machette, then returning to the gunfight full of misguided confidence. The machettee might be better than a butter knife, but in a gunfight it’s not exactly the best tool for the job at hand. And SVN is to modern version control what a large piece of warm, soggy lettuce is to both grastonomy and flagellation — an entirely unsatisfying experience.
No I do not want to have a meeting to discuss my attitude problem. Merely expressing a subjective opinion.
Oh, and to make matters worse, the build systems for some projects have weird dependencies on the actual SVN revision numbers? Making moving projects or splitting up the central repository tricky at best and insanely complicated at worse? This just keeps getting better and better.
No, I certainly do not want the job of build controller. I’ll shut up now.
With teeth gritted and expectations suitably lowered, I will adjust my workflow to SVN…while silently closing my eyes and thinking of Git…
Some obscure (and not so obscure) SVN tasks
SVN diff without unified diff format:
svn diff --diff-cmd diff -x -b <filename>
Merging cherrypicked changes (in individual files) from trunk to branch:
Check out branch:
svn co svn+ssh://svn/usr/local/svn/project/branches/ver_1_42/ ver_1_42
Find revision number of change on trunk:
svn diff -c 9176 file.c
Change current working directory to branch checkout and merge just the changes in the specific revision from the trunk:
cd ver_1_42/src/sub/dir/ svn merge -c 9176 svn+ssh://svn/usr/local/svn/project/trunk/src/sub/dir/file.c file.c
Rinse and repeat for all files as necessary.
(This worked, but in this case I was only interested in the changeset from a single commit/revision, albeit with many files affected. Might not work as well across multiple revisions?)
Revert changes from one file on new branch (reverse merge from trunk):
cd ~/checkout/project/tags/ver_2_41_3/src/sub/dir svn merge -r 1449:1448 svn+ssh://svn/usr/local/svn/project/trunk/src/sub/dir/file.c file.c
Comments