Subversion merging and branching

by kai on 14/04/2007



Well, this is not particularly on architecture. Just the other day the dev team of one of my current projects released a 1.0 alpha version of the product (no, although it’s a very cool Flex application, I can’t give you a public url right now – stay tuned for a few more days). The fact that we’ve basically released some first version that went to staging/production now implied that we had to revisit the way our subversion code repository was set up.

We finally realised that we needed to introduce proper branching and merging. For soneone who doesn’t really enjoy working with CVS, this is interesting as Subversion’s branching and merging concept are imho significantly easier and absolutely straight forward compared to the woe one had to fight with when using CVS. But anyway – while we changed the repository layout, I came across two extremly helpful tutorials/articles, I’d like to share:

Subversion branching quick start

Streamed Lines: Branching Patterns for Parallel Software Development

The latter is written from a rather abstract point of view and independent from any paticular versioning product but a very recommended read about the patterns and general ideas behind branching.

Funny enough – in another project we’ve just introduced a proper versioning system as well (they were using Visual Source Safe before, which I don’t consider to be a proper versioning system, sorry – that would be as to call Access a proper enterprise database system that should be used in web applications…). There we’re going to use CVS and some people fought a hard fight to establish exclusive checkouts of code. With this terminology, I don’t refer to having private branches per developers and merging them together at some later stage – this might become necessary in very large projects; what I refer to is locking and unlocking files in the trunk whenever they are used resp. stop being used. I was heavily argueing against that because it’s one of the silliest ideas I can think of for a ca. 10 person CF web development/testing team being located on the same floor. I would go even further and say the exclusive checkouts are absolutely evil.

What do you guys think about exclusive checkouts? Any opinion?

{ 5 comments… read them below or add one }

Adam Cameron April 14, 2007 at 12:00 am

When we shifted from VSS to SVN, some of the team couldn’t get their brains around the notion that files don’t NEED to be exclusively locked. SVN does a good job of merging files, and – when one steps back – it’s pretty rare for two developers to be working on the same line(s) of code in a given file anyhow.

Since shifting to SVN, I’ve never needed to even *consider* exclusively locking a file, let alone actually doing it.


Adam

PS: white on black is a really crap colour scheme for readability, btw.

Reply

zac spitzer April 14, 2007 at 12:00 am

If your on windows, TortiseSVN is great, you can even add columns in explorer to list SVN properties in the file details, like owner, revision etc

haven’t been able to set it recursively unfortunately, you need to do it on a folder by folder basis

Reply

Jim Priest April 14, 2007 at 12:00 am

Exclusive checkouts sound good but why bother when SVN takes cares of that for you? BTW – the TortoiseSVN client has a great Help section… Very well written.

Reply

pan69 April 15, 2007 at 12:00 am

@zac spitzer

Just right click the base svn folder of your project and select ‘properties’ from the context menu. There should be a Subversion tab. Set your svn:keywords there and in the bottom left corner there should be a ‘Set recursivly’ option.

Reply

David Harris April 16, 2007 at 12:00 am

We’ve been using SVN now for well near 2 years at work and I can count on one hand the times I’ve had to resolve conflicts in files. (a conflict is when two people have changed the same line in a file before committing)
Even then resolving the conflict took about 10mins.
We used to use VSS, and I find SVN’s approach to version control much better!

Reply

Cancel reply

Leave a Comment

Previous post:

Next post: