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?
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.
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
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.
@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.
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!
Comments on this entry are closed.