betabug... Sascha Welter

home english | home deutsch | Site Map | Sascha | Kontakt | Pro | Weblog | Wiki

12 July 2006

Wondering About CVS branch Strategy for a Webapp

Back and forth on releases, branching, and merging

At work we have one main web application, that really runs in one instance on our production server. This is all based on Zope's filesystem based python products, so all our code is in cvs. (Yes, I'm too lame for svn or other more modern revision control systems). Now this is a bit different from normal software release cycles, since with a webapp, I can "upgrade" the application a couple of times a day when we get new features or bugfixes. No need to ship new releases to customers... but how could I handle code change management with this? I researched things, but I've still got some open questions, so come and see what I've been up to...

What we have so far is that we develop our new stuff on the trunk (cvs's HEAD branch), and we've got a branch for "production". For a while we had most of our work in a separate branch, which I would merge with the production and HEAD branches. Since I'm no real expert at cvs, this caused lots of mess and time lost each time.

New branch on each release

My current plan is to go forward on the trunk, then with each "release", we create a new production branch from the trunk. This is very clean and allows for bugfixes on production, but if there are a lot of "releases", we will get real loooooong lists of tags and branches on the files. So, is this a good choice?

Merge HEAD to branch?

Another strategy would be to use the trunk for development, and have only one branch for production. I would then merge the trunk to the production branch when we have "releases". Problem is, I don't know how to do this, my knowledge about the cvs up -j ... dance requires using branch names. Anyone of my readers know how to do this? (Yes, I'm looking at all 3 of you!) And I'm not sure I won't have to use lots of tags too. (Update: use HEAD as the branch name, as in cvs up -j HEAD, as I was told on #cvs. Duh!)

Tag, export, tar, release...?

Another one: Just tag releases, export the source and do code upgrades on the server without having a real cvs checkout there. Hmmm. It sounds inconvenient, but maybe is really clean. There won't be any "just check that in and cvs up on the server" any more, but maybe that's a good thing. Branches for the "production release" would only be done when they are really needed for bugfixes. This could maybe lower the number of tags and branches in cvs.

So, I'm all open for input! Use the comment form, mail me, or pester me on #bsdcow if you feel like.

Posted by betabug at 13:16 | Comments (2) | Trackbacks (0)
ch athens
Life in Athens (Greece) for a foreigner from the other side of the mountains. And with an interest in digital life and the feeling of change in a big city. Multilingual English - German - Greek.
Main blog page
Recent Entries
Best of
Some of the most sought after posts, judging from access logs and search engine queries.

Apple & Macintosh:
Security & Privacy:
Misc technical:
Athens for tourists and visitors:
Life in general:
<< HelMUG Athens Meeting on Sunday | Main | Escape to Hydra >>
Re: Wondering About CVS branch Strategy for a Webapp

Ok, not really a Zope Example, since I'm learning yet, and I have not tried Products and so on.

But what we at codigo23 do is have only one branch (HEAD) in the cvs server. We keep working with that sources, and if we add new functionalities, correct some bugs or whatever, we perform a clean checkout of the code and then we offer that one to our customer (as an upgrade). This way we get only one cvs branch to maintain, and regular "snapshots" of the app.of course later on you can get such a snapshot using date tags (like doing a checkout of the code as of 12-11-2003, for example).

We work that way with webapps on top of php and python (using mod_python), aswell as some python-gtk apps.

Posted by: Wu at July 16,2006 04:55
Re: Wondering About CVS branch Strategy for a Webapp

Hey Wu! Yes, that would be the last of the mentioned strategies (tag, export, tar, release...). I think it's very clean, especially when you have multiple customers on the same code. In our case it's only one installation, but it's still a clean solution.

As I've found out how to merge from HEAD to our production branch, for the moment I'm going with that strategy. We'll see how well it works out.

Posted by: betabug at July 16,2006 11:13
You can trackback to:
There are no trackbacks.