4 ms·

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 Gi

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.

spacemanaki 15y ago
Which is apparently what Assembla has done for internal product development: http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...
wccrawford 15y ago
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.
- billybob 15y ago
  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?
  - wccrawford 15y ago
    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.
- elviejo 15y ago
  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?

spacemanaki 15y ago

Which is apparently what Assembla has done for internal product development: http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...

wccrawford 15y ago

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.

billybob 15y ago
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?
- wccrawford 15y ago
  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.
elviejo 15y ago
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?