Show HN: SVN Branching as easy as Git | Hacker News Reader

Show HN: SVN Branching as easy as Git

blog.lagentz.com

14 pointsgrexi8 comments

This is one region where Mercurial particularly shines: things like hg-git and hgsubversion. I believe hgsubversion even supports translating from hg branches to svn branches.

(Git's model is restricted enough that it can't very successfully act as an interface for Mercurial or Subversion. Mercurial can do both very well.)

I had to use an SVN repository this semester at Uni. Only once did I actually check it out in SVN—then I decided to chuck that and use hgsubversion. That made me considerably more productive than the other students... especially when the SVN server ran out of disk space: I could still commit and push later, while they had to wait. :-)

When I have to deal with Git repositories, I typically use Mercurial, also.

One question: Why?

If you have large SVN repositories in production, it's often not easy to switch to git. But you'll get some comfort back with those aliases :-)

I have a 1.4gb SVN repo (working copy checkout, so more like 700mb actual files) with 15k revisions. Horror of horrors, I pulled up the first commit message and look what message I found:

    commit ...
    Author: (no author) (no author)@...
    Date:   Sun Jun 8 ... 2003 +0000

    Standard project directories initialized by cvs2svn.

    git-svn-id: ...@1 ...

If you've got more than 15k revisions, larger than 1.4gb working directory, or a codebase that is over 10 years old then keep talking. Otherwise get over yourself and use git-svn.

170k revisions and several repositories totalling half a TB, with some working directories in the high double digit GBs. Given that we have no performance or reliability problems, and our server isn't particularly beefy - just problems with branching - I wouldn't be surprised if people have an order of magnitude larger repos.

(Game development shop with art assets in SVN)

The KDE Subversion repository had modules with upwards of a million revisions. Most have been moved to git, and had to be split into much more granular git modules (though technical concerns were not the only reason that was done, we wanted more modularity anyways).

Btw by large SVN repositories I also mean "many devs with checked out working copies" and "many devs which know their workflow reasonable well".

The conversion tools work well, but bringing 200 devs to a new system can be a major PITA.

And look, the irony, I've added my aliases on github.

I'm no brain dead svn fanboy.

Reply on news.ycombinator.com