svk, we're done; hello git-svn.

October 23, 2007 - 11:17pm — frank

OK, I give up. I tried my best to work things out with svk, but it wasn't meant to be. I could have saved myself a lot of pain had I listened to other's experiences, but I wanted to give svk a fair shot. Having done that, I'm happy to say I'm a git-svn user now.

If you are trying to choose between svk and git, let me give you a sample of the pain you can avoid by using git ...

Let's start tracking an SVN repository with svk:

# first make a mirror
svk mirror //mirror/boodebr https://boodebr.googlecode.com/svn/trunk/
svk sync //mirror/boodebr
# of course, disconnected operation doesn't work with the mirror,
# so make a "local" copy
svk cp -p -m "Make local repo" //mirror/boodebr //local/boodebr
# NOW check out a working copy from the local copy of the mirror
svk co //local/boodebr

Now with git-svn:

git-svn clone https://boodebr.googlecode.com/svn/trunk/

Merge remote changes into local copy:

svk sync -a
svk smerge -lt .

Sorry, can't use svk pull because sometimes it gets confused and will make you merge the exact same changes //again// when you push later.

Now with git:

git-svn rebase

Push changes back to subversion:

svk smerge -Ilf .

Except of course when you can predict that will fail, in which case you should have done:

svk smerge -lf .

Push changes with git:

git-svn dcommit

Remove a working copy when you are finished with it:

# don't forget to "disconnect" it or svk will get confused!
svk co -d dir
rm -rf dir

With git:

rm -rf dir

And this doesn't even touch on issues like ...

svk has about a zillion dependencies making it brutal to install on anything other than Windows
svk has no GUIs; you can try the svn GUIs but you have to be really careful not to screw things up
svk won't let you mirror (and hence checkout) a repository more than once
even though svk offers "disconnected" operation, you are locally tied to its centralized "depot" and have to remember things like which trees are remote mirrors vs. local mirrors, which working copies you forgot to disconnect, etc. In git, each directory stands alone (like every other distributed VCS).
... and of course all the other benefits of git, which are well documented elsewhere.

svk does seem to have a lot of fans, and I think choice is a great thing. For all I know, it may seem 100% more natural to a subversion user than it does to me. But coming from a distributed-VCS background (first darcs, then mercurial, and now git), I just couldn't get the feel for svk.

Written in WikklyText.

frank's blog

Comments

July 17, 2008 - 8:14am — Chris (not verified)

Branching/Merging

Granted, Subversion 1.5 just got a lot better, but branching/merges in git is so it there's not reason not to use it for every pile of changes you want to make (I just started git 2 days ago, might be wrong)

git checkout foo
...do work in same directory
git checkout master

Switching between branches without adding (staging) applies the changes to the new branch automatically. You can also do

git checkout foo
...do work
git commit -a
git checkout master
git pull . foo

I mean, it could be slimmer, but it certainly is painless branching/merging.

December 14, 2007 - 5:44am — M.S. (not verified)

mercurial -> git: why?

Hello Frank,

why did you change from mercurial to git?

December 14, 2007 - 8:52am — frank

mercurial -> git

I think mercurial is a very good choice too. What really hooked me was the first time I ran git-gui — wow! It's funny - all the websites I had read about git sang the praises of gitk but never really mentioned git-gui. I had never liked a VCS GUI until I used git-gui. I seem to recall trying out a port of git-gui to mercurial but it didn't work for me.

So, the deciding factor was finally finding a usable VCS GUI tool, nothing really to do with the technical side of things. I would have no problem using mercurial again if it had git-gui and gitk equivalent tools.