The Old Joel on Software Forum: Part 3 (of 5)

Source Control

Can anyone recommend me a good document describing the various methods that can be used in oraganizing source control, nightly builds and things like that?

I am not looking for a software recommendation but rather a document explaining methodology. Microsoft has one on their site.

http://www.microsoft.com/downloads/details.aspx?FamilyID=94fdb8c8-5a87-4545-af75-6053f32c7eca&displaylang=en

It's not bad, but I thought I might check other ideas before starting to change the whole way we work.

Eli Golovinsky
Monday, December 29, 2003

Quite a lot of stuff available through www.cmcrossroads.com

ps. source control is one thing but while you're at it think about change control too... poor (or no) change control is normally a good way to waste money...

Gwyn
Monday, December 29, 2003

not to be rude, but there's been significant discussion of this topic on this board and many JoS regulars have provided good info on source control and related topics.

You might try searching right here -- not only for 'source control', but also for "configuration management", "cm", and as somebody else suggested, "change management".

also, search for individual tools that address this area. A few that come to mind include "cvs, vss, rcs, star team, source safe". I know there have been many other source control / CM tools mentioned here as well. I suspect you'll find the search results quite helpful.

anonQAguy
Monday, December 29, 2003

Strange, whenever someone mentions SourceSafe and the other mickey mouse versioning tools I just want to shout "CRAP!"... and it's true... trouble is the only alternatives (that attempt to do the job seriously) are things like Continuus, Clearcase, PVCS Dimensions and they're sort of better, they have change control and things like directory versioning built in .... but the truth is they're not ideal and very very VERY expensive for what they do.....

Gwyn
Monday, December 29, 2003

Well, Gywn, I "feel your pain". However, I've had and heard pretty widely varying experiences with the different tools. Personally, VSS has worked ok where shops I've been at have used it. However, I've heard a number of folks describe lots of problems they had with it. Same sorts of variations for other tools. Mileage seems to vary quite a bit with these tools, or maybe folks just get kind of "religious" about them... don't know.

For my part, as a QA Manager, the biggest problem I've had with VSS or any of the high-end change management tools at any shop is getting people to 1) use them, and 2) use them correctly.

As to the additional features you mention, VSS and many of the other tools are only designed to do source control, i.e. version control of document-type artifacts. They are not designed to handle more general change management tasks.

Handling general purpose change management tasks, which covers a lot else basides AND includes version control on all the related artifacts (not just code or document-type artifacts) is a more complicated problem. So while it certainly hurts the wallet to pay for such tools, at least up front, I don't see how such tools could be made simply or cheaply and still have enough capability and reliability to be worthwhile.

anonQAguy
Monday, December 29, 2003

Eli,

You might want to look at this article for a good introduction to SCM:
http://www.perforce.com/perforce/understanding.html

And this article for some best practices:
http://www.perforce.com/perforce/bestpractices.html

Regards,

Mark

Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128

Mark Pearce
Monday, December 29, 2003

Here's one. Developement is always the trunk. Branch off versions and make those branches bugfix only. Merge the branches back into the trunk if need be. Have a daily build (cruisecontrol from sourceforge is good.). Daily change logs. Commit emails. Cross referenced source code ala javadoc or doxygen. Todo lists and objectives.

Tom Vu
Monday, December 29, 2003

Development should never be on the trunk. The trunk is what you release. When a developer wants to fix a bug they make a branch off the trunk. When you're going from 1.0 to 2.0 you make a branch off the trunk.

The trunk is sacred. The trunk compiles. The trunk passes unit, integration, and system test suites. Thou shall not dick with the trunk.

Snotnose
Monday, December 29, 2003

That was and generally still is my idea of using source control, especially in large groups, that the trunk is sacred and anyone that breaks it has to fix it, no untested code (and that means system and unit tested), goes into the trunk.

However, the Mozilla development never seemed to work like that, version milestones became new branches with all the work on the branch committed to freezing it, whilst the trunk kept on going frequently foobarred and with issues like 'does this fix in the trunk belong in the release branch/does this freezing fix in the release branch belong at the tip?

Perhaps it was the right method to use in a 'develop in public, release often' scenario; but it gave me the heeby geebies.

Simon Lucy
Tuesday, December 30, 2003

Holy trunk!
Now seriously, consider Subversion (SVN), especially with a Windows client such as TortoiseSVN ( http://tortoisesvn.tigris.org/ ).
Change-control, CVS style. Directory versioning, plus rename and move is supported as a versioned operation. Diff-merge also included. Quite strong but simple to use.

Tal Rotbart
Tuesday, December 30, 2003

There are approaches in which the trunk serves as the development branch and other approaches where it's what you release. Either strategy can work just fine so long as you're consistent about it.

Karl Fogel's CVS book (http://cvsbook.red-bean.com/) has a chapter about different branching strategies that's really worth a read. I recommend this book every time CVS comes up because it helped me go from being really uncomfortable using CVS to managing CVS for a development team.

Beth
Tuesday, December 30, 2003

Brad Appleton and I wrote a book that covers some key SCM practices that might be relevant :
"Software Configuration Management Patterns: Effective Teamwork, Practical Integration" by Steve Berczuk with Brad Appleton. The website for the book: http://www.scmpatterns.com has some links to other resources and books that might be helpful as well.

Steve Berczuk
Tuesday, December 30, 2003

Coincidentally, this just showed up today:

Pragmatic Version Control Using CVS
http://books.slashdot.org/article.pl?sid=03/12/17/2033254

--
Tuesday, December 30, 2003

I wrote an overview for O'Reilly Net that does just that (and then includes an overview of popular open source options). Send me an E-mail at shlomif(at)vipe.technion.ac.il if you wish to receive it. (it's not published yet)

Shlomi Fish
Thursday, January 1, 2004

"Development should never be on the trunk."

Baloney! You don't build from the tip of the trunk, you build from a label or snapshot or whatever your version tracking software calls it.

You branch when you *must* branch, and not otherwise. Doing that, your revision tree will look like the actual evolution of the code, which predominantly follows a linear course of improvement, except for bugfixes to old releases, perhaps customized releases, and perhaps (rarely) wild experimental tangents. If your linear progression drifts down a dead alley, you can always revert by copying an old revision ahead to the tip, but since that's by *far* the uncommon case, keep the complexity with that case, and not in the day-to-day case.

Convoluted and cockamamie models of programming behavior just lead to grief and lost energy. But of course they can be used to justify the profession of the nonprogrammer "configuration manager", so they're rather in-vogue in these days of encroaching by so many outsider-specialists into the programming world.

veal
Saturday, January 3, 2004