The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Version control strategy for frequent releases

My company needs to improve our strategy for branching and releasing, but I'm not sure what the best approach is. I've been looking at http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html for some ideas on branching patterns, but I'd like to know if anyone has a recommendation, or experience to share.

* We do frequent releases (usually once a week).

* It's a web application, so there's only one version in use at any time.

* Some changes need to be in development and testing for a long time, while others are quickly made and released.

* We need a way to know which changes (from our issue tracker) are part of a given build. We're perfectly happy to modify our issue tracker to help with this.

* We're using CVS now, but might consider switching to Subversion if it would help.

Thanks.
JW
Tuesday, October 16, 2007
 
 
For my larger web projects we run Subversion right on the production server.  We have a *single* release branch that we merge changes to from other branches (trunk, testing, versioned branches, etc). 

Production releases involve a merge to the release branch and then an SVN update on the server.

I'm not sure if this is helpful information for you.
Almost H. Anonymous Send private email
Tuesday, October 16, 2007
 
 
Your situation is similar to mine.

There's basically two approaches. You can do it the way Almost H. Anonymous does it, or you can check your releases out from the trunk and create branches for any changes that will take a long time to develop/test. The drawback to the latter approach is that sometimes you don't know in advance which changes will merit a branch. The advantage is that if you release from the trunk instead of creating release branches, your production copy of the site can be a working copy that you upgrade by running cvs update.


> * We're using CVS now, but might consider switching to Subversion if it would help.

Switching to Subversion will help a lot if you plan to do a lot of branching and merging. It's not perfect, but atomic commits are a big win over CVS in that kind of environment. Be prepared for some migration headaches, particularly if your CVS strategy is tag-centric.
clcr
Wednesday, October 17, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz