Apr 07

More Distributed Revision Control

Tag: UncategorizedSymon Rottem @ 9:40 pm

Following up on my last post about distributed revision control systems it seems that the buzz is all around town now…am I just late to the party?  I just saw the Ken Egozi has started trying to get off the ground with Git.

I’ve been doing a bit more research to understand what the phenomenon is all about and I think this comment (which I’ve trimmed slightly for brevity) left on Coding Horror by Vincent at Genezys (blog in French) explains some of the reasoning nicely:

…I agree with you about distributed source control that it is not easy to see the difference with centralized source control…this if often a misunderstanding of what a source control system is. I think all programmers will agree with me that source control system allows:

– to work on a common source code ;
– to keep an history of the changes ;
– to back up your work.

The order I choose is intentionnal, this is the way people understand source control. First I can share with others, then I save history, and then I feel safe because my code base lives in a secured server.

With distributed source control, the goal is primarily to keep an history of the changes. Sharing the code is secondary. Backing it up is not even a feature.

That is why it is so confusing to switch to distributed source control. With distributed source control, history is the main thing. They considered this feature so important that they allow you to browse your history while being offline. You can share with others later.

There is some advantage to that. First, this is much harder to break the build. You don’t have to push untested code or quick and dirty fix “just to save them” because you can save the history locally, do all the testing another day, and finally merge the whole history back with others.

Merge are easier too. With SubVersion, when a conflict occurs, you MUST resolve it before commiting your changes. But you may not understand the conflict and you really really don’t have time to fix that right now. Because distributed source control keeps a whole repository locally, merging is not mandatory when a conflict occurs. You can keep the two versions and choose to resolve the conflict later. Or even ask the programmer that introduced the conflict to fix it.

Personally I’m still a little hesitant to migrate anything I’m working on to a new revision control system at this stage; Subversion is working very nicely for me at the moment, and I’m not sure how mature the GUI tools are for working with these systems…and I do love my full coverage GUI tools. Excuse me while I go and make an offering to the Tortoise gods…

Regardless of my reservations on my own projects, I can certainly see the value for a larger, more distributed projects such as the Castle stack, NHibernate (which are not using DRCS at moment) or Ubuntu (which is) where the development team is distributed and the code base takes some real work to grok. It would be really nice to be able to work on the code for something complex and be able to check in while experimenting so a roll back would be possible if the wrong path was followed – and this is not easy with Subversion if the repository is remote and even more so if you don’t have write access.

If anyone has any broad coverage GUI tools to recommend for use with the current crop of DRCS-es I’d love to hear about them.

On a side note, I did stumble across a project that uses Subversion into a DRCS called SVK which was interesting. I don’t know how it stacks up against the others, but interesting nonetheless.

Related Posts