Forum OpenACS Q&A: Getting ready for beta - tagging and branching CVS

I spent some time studying CVS docs today, and think I've figured out
what I should do to prepare our CVS tree for beta and final releases.
Afterwards I read Ron Henderson's old doc over at the ASJ and he
seems to recommend the same plan, so maybe I'm on to something!

Here's my plan - let me know what you think.

Very soon (tomorrow?  Let's see how much feedback I get to this post)
I'll branch the tree, making an OACS-4-5 branch.

This will require developers who want to make bug fixes to this branch
to update their tree using a "-r" tag (I think that's right, I
certainly intend to re-read docs before doing so!)

Folks who want to move forward on the main branch (etp2.0, for
example?) can do so then without interfering with our release process.

When I think the beta's sound, I'll tag (not branch) the tree with
OACS-4-5-BETA-1, which people can download (I'll make a tarball, too)
and use as a reference point.

Later I'll tag a "OACS-4-5-FINAL" though there may be intervening
steps (we've gone on so long I think we can skip the traditional
"release candidate" step just this once?  complaints?)

Then I'll merge bug fixes with the main branch and weed out any conflicts.

Does this sound like a plan?

Using CVS then becomes slightly less obvious for folks doing
development, because you have to be careful to do your work in the
right branch.  Those working on the main development branch won't have
to do anything special, just those fixing bugs in the beta version and
those wanting to work on both branches (you'll need two checkouts).

It will be important to remember to cvs update with "-r"
appropriately, or make a new checkout, when you decide to flip from
one to the other.

OK ... the floor's open for comments!

<blockquote><i> Once you have a working copy tied to a particular branch, it remains there until you tell it otherwise. This means that changes checked in from the working copy will add new revisions on that branch, while leaving the main trunk and other branches unaffected
</i></blockquote>
This is the danger, I guess, forgetting to switch to the right place if you flip-flop.
<p>
So perhaps the thing to do is to maintain personal directories for old releases one works on and provides bug fixes to, and a "develop" directory for the latest branch?  With the flotilla of nsd.tcl and start-up scripts that implies, and different db instances, etc.
<p>
Well, at least those last things aren't due to CVS!

Every time I have to do something even remotely complex in CVS, or watch someone else trying to do it, I think "there's got to be a better way".

Is there any interest in evaluating Perforce, after the 4.5 release is out?  It's not Open Source but they do give free licenses to Open Source projects.  I have not used it but I have been curious about it, and I believe aD switched to it towards the end (not that this is exactly a ringing endorsement, considering their other choices of tools at that time :).

If there is interest, I'll set up a copy for us to evaluate when Don feels he has sufficient time to look at it.  I'm also open to looking at other tools, if anyone else has a favorite.

I think CVS is OK as long as we keep the complexity level down and do everything in a rote manner.  The PG group has managed to keep its sanity with it.  The major benefit is that most people who do Unix hacking have used CVS before and are used to it.

Perforce is supposed to be good, though.  The Linux folks have never used a source control system in the past because of Torvalds's personal bias against such things, but they've started using Bitkeeper recently and apparently like it.

So ... we can certainly explore if folks want to.  CVS gets painful when you're trying to keep your private custom stuff merged with a public tree.  Keeping the CVS tree for the project itself seems simple enough, it's just our users who will suffer if they are trying to keep a private tree synch'd with ours.

So it's probably our users who will be most motivated to explore a superior solution!

Janine, if you want to take a look at something better than CVS, might as well look at subversion too, the new incarnation of CVS. It solves many of CVS' current woes, but it's still in 0.9.x version, but getting pretty close to 1.0. And it's free software.

Bitkeeper and Perforce are both superior to CVS, but not to what Subversion will become when it grows up.

I brought up Subversion, Bitkeeper and Perforce (see the <a href=https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002O0&topic_id=OpenACS&topic=11>"Bitkeeper Experiences?" thread </a>) a few months ago when first laying out the new OACS.org. It wasn't a very popular suggestion to consider Bitkeeper or Perforce over CVS in the new site because neither of them are OSI compliant. But as Janine said, both offer their systems free of charge for open source projects.
<p>
Roberto's right that Subversion will probably wup both of them, for no reason other than it will be open source (Apache license). IIRC, the guys building it are some CVS gurus who got fed up with CVS' limitations. They've been working on it for two years (I think that Cygnus originally commisioned it's development). It's currently scheduled to hit 1.0 release in late May, but we all know how stringent open source projects deadlines are. The other problem with Subversion is that even with it's release, there may still be a lot of bugs with the CVS migration tools, docs, etc. They are self-hosting over there, but they are probably just dog-fooding.
<p>
Since the new OACS will be coming alive around the same time as the release, Subversion isn't ready totally ready for prime-time and people are truly interested in a compelling replacement for CVS, maybe we should consider Perforce or Bitkeeper for the time being.  Everyone at aD raved about Perforce and if Bitkeeper can handle Linux development how bad can it be?
<p>
Personally, I don't care one way or the other because I'm not a hacker/geek/nerd/vinod, but it does seem like the are a whole bunch of complaints about CVS...
<p>
talli

I think my preference at the moment would be to stick with CVS for now (we've got a lot on our plate and it's going to stack higher once we release and start doing some of the tasks we've been discussing in the Design forum).

If subversion's coming out in May I'd probably like to give it a try because they'll have a compelling self-interest in getting the migration tools to work.

If it were to look like they're way off in the future with a meaningful release, we could look into Perforce or Bitkeeper.  I'm not so concerned about the fact that they're not Open Source, just free, more with an assumption that Subsersive is more likely to provide an easier migration path and their docs surely will be pointed towards the existing CVS user (part of an easier migration path!)

Of course I could be all wet ...

I just checked the Subversion project page and it looks good, as it takes care of a couple of the major issues with CVS:

1. commits will be atomic, no more halfway-commits if your ISP goes out of business half-way through a commit.

2. multiple merges will be handled gracefully, they hope.  That would be nice.

3. branching handled in a more natural manner, rather than being a special kind of tag it will be a special operation on a tag.

These are nice.  There's some other good stuff but these seem like the three major ones.  Making merges and branching easier to use would solve the #1 complaint folks have with CVS I think (?)

They say they're keeping commands and options as close to CVS as makes sense, which would be handy for those who are used to just grabbing sources now and then.

<blockquote><i>If anything, Don, I might wait even longer next time before branching, (perhaps even waiting until you cut the beta code)
</i></blockquote>
Actually, I am cutting the beta code.  I wanted to branch off when I started so I would know for sure what I've got.  I do think this is the right time to branch, i.e. as soon as you start making releases.  Next time I plan to branch at our first alpha, but also next time I don't expect to see six months pass between first alpha and a beta!  A few weeks, max!

Please, let's not move OACS away from CVS unless the benefits are truly substantial.  I'm no CVS expert, but I know it well enough to
(usually) get it to do what I need from it.  And, as others have said, if a change of version control software really is going to be worthwhile, then let's at least make sure the new one is free software, as free as OACS itself.  Otherwise the version control software could easily become a barrier to entry for OACS developers.

BTW, there seem to be quite a lot of small (tiny!) changes on the untagged development branch compared to the tagged oacs-4-5 code.  Already!  About 78 files across 14 packages are affected, based on a cvs diff command I executed this morning.  Am I just overly suspicious, or are all of these really things which are sufficiently
dangerous that they need to be left out of the first beta release?

Last but not least: get well soon, Don!

Aha.  Don is correct, the changes are only in the tagged branch.  I take it they will eventually be merged back in to the development branch -- as soon as the beta release is tagged?  Or only after the final release is tagged?

Meanwhile, those who grab sources and do things with them other than develop long term new functionality (such as testing, testing installation, creating RPMs, debs, windows installable packages, etc etc, should probably work with the tagged oacs-4-5 branch. Only those doing long term development work should use the default (untagged) branch.

Question: Should nightly tarballs now use the tagged branch?  If not, fixes made to important bugs will not be visible to testers who use the nightly tarballs, which could confuse people, and/or reduce the usefulness of their testing. How easy would it be to arrange that the nightly tarballs are built using the tagged branch?