Wondering About CVS branch Strategy for a Webapp

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.

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

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.

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.