Moving from SVN to ...?

Question

I'm currently working in a team where we're "using" a subversion repository. I say "using", because in reality, everyone's just editing files directly on a server through samba shares, while every once in a while our architect does a commit from that server with our changes, which are then pushed out to servers.

So basically we're missing out on being able to have meaningful commit messages from different users, and being able to commit as often as we like.

I've been trying to spark some interest about distributed systems, and how the workflow that we have seems like it could be set up very nicely with something like git (us committing on our local machines and then pushing changesets to him for review) but i don't feel that i have enough experience with git. Most of my DVCS experience has been with mercurial.

Everyone is pretty much working in a windows environment using tortoisesvn, and that's the way they're used to interacting with the system, but they occasionally use PuTTY to work on one of the linux servers, and know how to do a commandline commit.

What is the way to go with this, i've seen some of the work being done to create gateways between SVN and some DVCS'es, does anyone have any experience setting up and working in such an environment?

How about full-scale migrations from SVN to a DVCS?

Answer 1

Is there a reason you don't want to just keep your SVN repository, and use it in the way that SVN is intended to be used?

Why not just have everybody checkin and merge, use branches, etc? Why switch if you have a repository setup?

Answer 2

It seems that the problem you're describing has mainly to do with proper procedures and protocols for commiting code. getting a differnt product would not change the way people work. you need to educate them first. show them how to do things better.

On a different note, I didn't get how you use tortoiceCVS for interfacing with SVN.

Answer 3

both git and bazaar has good support for svn. infact git-svn has matured quite a bit over the last few months.

try out git, for a DVCS is really nice, and aint that tough as you make it sound like.

Answer 4

git-svn is definitely your best bet here. You'll be able to use all of the local version control and change review features of git, but ultimately can push up "final" check-ins to your existing svn repository.

This has the awesome side-effect of being able to let your team get their feet wet with git a little bit at a time (both because you can try before you buy and because you can still use any existing deployment/maintenance processes that you've developed using SVN).

There's also a good crash-course on git syntax for svn users that you can use to get your team up to speed.

Answer 5

hg is quite good at working with subversion, too -- see http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion . The Python core development team just decided to switch from Subversion to Mercurial (after a long discussion &c period where git and bazaar were also considered); in an unrelated development, code.google.com's free hosting service for open-source projects added hg support to their long-standing support for svn.

Answer 6

If your team can't understand how to use subversion well, I don't know how you will be able to get them to understand git. Especially since they are in the mindset of "lets all work in the same working copy," they are going to have a hard time grasping a distributed version control system.

In my experience, to use svn-git, you have to know how to use git AND you have to know how to use svn. I'd recommend teaching them to use svn correctly.

Answer 7

To me it sounds like the choice of a version control system isn't the issue. What you need to do is convince the architect that he needs to come up with some sane policies to use a revision control system.

Your current svn system would be perfectly adequate; let users create branches if you need to keep trunk clean. The architect can merge them in as he needs to.

Now, you could move o a DVCS and there are good reasons to do so. But if the team isn't used to using a client/server rcs then this may prove challenging. And you could use git or hg locally but these are workarounds to a fundamentally broken rcs usage. Get everyone on to using svn first would be my suggestion.

Editing files on a samba share?? Seriously?!

Answer 8

Your problem is not SVN itself but not using it properly.

Answer 9

As Steve Yegge might say: TOOOOOLS

As others say, if you can't get them to use svn, they won't use a distributed vcs.

Do they use IDEs? If so, find plugins for the IDE that make it easy to use svn. So they can right click on a file or folder in the IDE and check in. If you make it easier to use source control on a local copy than to access the central files directly you might stand a chance. Then you can use TortoiseSVN for more complex tasks.

Some links to SVN plugins for popular IDEs to get you started:

• Visual Studio - AnkhSVN and VisualSVN
• Eclipse - Subversive and Subclipse
• Netbeans - Subversion

And here is a list of IDE plugins from the subversion website.