It's Time to Fix Subversion Merge | Hacker News Reader

It's Time to Fix Subversion Merge

blog.assembla.com

10 pointsnreece16 comments

This is a good write-up on how to build this, but it should be stated if you've grown beyond what subversion can do you should switch your repository over to Git or something with more advanced functionality built in.

Which is apparently what Assembla has done for internal product development:

http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...

There's always 2 choices: Fix it, or replace it.

I think there's a good case for fixing Subversion. It's very easy to use (except for merging!) and it's got good adoption.

Git is harder to understand and use, but obviously merging is miraculously easy with it.

SVN took me about 10 minutes to learn. Git took me a week to grok the basics, and months to learn the finer points.

If I had to pick one of the 2 to train a new coder in, I'd pick SVN... If it had merging done well.

This comment on the original post is interesting: "Fixing svn is a lot of work. You could instead write a wrapper around git-svn to make it look like svn. The wrapper can enforce a centralized workflow. The user should not be able to tell the difference."

It's a neat idea. After all, which is easier: to fix the inner workings of SVN, or to provide a more SVN-like interface to Git?

That's a good point, too. It shouldn't be that hard to restrict Git's features to a subset that is easy to learn and pretty much foolproof. (Foolproof meaning you wouldn't need to dig into the advanced features.)

I wonder if someone has already tried to do this? It suddenly seems so obvious.

I've trained 10 develepers into using HG. And still seems to me that SVN is a lot easier to teach and comprehend. I don't know why this is... maybe the mental load of having a current directory + local repo + a remote repo. Makes it hard to understand?

If I recall correct, one of the lead devs of SVN has stated he is fine with svn merge as-is.

I strongly recommend migrating to hg or git if possible.

I'm using for my hobby project git, very slow learner, and it keeps me thinking if we decide to replace Perforce (P4) with git - how we are going to explain to people how it works - most of the people using it are actually not software engineers, but artists, producers, animators, etc.

Then how much HDD space we should allocate, after knowing that Perforce's own DB is in dozen terabytes.

How efficient git is with binary data. How would the team react when software engineers would work with git for the source, and the rest P4/SVN? You can't label the depot at once...

So there is probably plenty yet for SVN/P4/etc to be used. I myself fancy being cool and using git, but it's only for my hobby yet - I haven't heard of anyone using it at large in any big game development studio...

With git you only really need to care about 5-6 commands for basic usage. For more advanced stuff you could also use a GUI; for mac there are plenty of tools that are really polished.

That's fine, but the concept of intermediate storage (index) is not very easy to explain to an artist. Some of them still don't grasp all of P4, and P4 is very simple and easy - with changelists.

git commit -a -m "blaaaa"

or (my favorite!)

hg commit -m "blaaaa"

At least, that's how I do it!

If I recall correct, one of the lead devs of SVN has stated he is fine with svn merge as-is.

How quickly we become our parents. SVN was born as a reaction to the same sort of unwillingness to move forward on the part of the CVS maintainers.

Complaining about Subversion merge is like complaining about how your Apple IIe can no longer use modern software. Subversion and the Apple IIe are outdated and should be migrated away from.

It's time to let SVN die and switch to git.

use git -> fixed

use HG -> fixed

Reply on news.ycombinator.com