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!

That sounds like a winner to me, Don. Rarin' to go!! And yeah, the -r flag for updating sounds familiar to me...but it's been awhile since I've done bugfixes on a branch. I'll go back and reread as well.

Hmmm...from Cederqvist online (http://www.cvshome.org/docs/manual/cvs.html)

" 5.3 Accessing branches

You can retrieve a branch in one of two ways: by checking it out fresh from the repository, or by switching an existing working copy over to the branch.

To check out a branch from the repository, invoke `checkout' with the `-r' flag, followed by the tag name of the branch (see section 5.2 Creating a branch):

  $ cvs checkout -r rel-1-0-patches tc

Or, if you already have a working copy, you can switch it to a given branch with `update -r':

  $ cvs update -r rel-1-0-patches tc

or equivalently:

  $ cd tc

$ cvs update -r rel-1-0-patches

It does not matter if the working copy was originally on the main trunk or on some other branch -- the above command will switch it to the named branch. And similarly to a regular `update' command, `update -r' merges any changes you have made, notifying you of conflicts where they occur.

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.
"

<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!
Sounds great Don. Onward, onward!
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.

Where could those of us who don't have check-in privileges post bug reports on 4.5?  Will there be a space on the SDM set up?
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!

Paul - just report bugs in the SDM for the general "4" project for now.
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.

Perforce is very good, and solves all the frustrations I have with CVS.  Atomic commits, true changesets, really good integrate facility -- I like it a lot.

I do plan to take a look at subversion though when it comes out.

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
Looking at the Perforce info on OSS projects use (http://perforce.com/perforce/price.html, scroll down the page for the section), I see that the license is "limited" to a certain number of users. I don't know what this means. I don't know if you can say that 1 Gazillion users will access the perforce server, or there is a set number of registered users that can access the system.

Either way, that kind of sucks. I don't know how they set it up though, so it may be more manageable. The point that you need to interpret legalese just to use their stuff seems to defeat the purpose of a free software project.

But if the system really is worth using for software development, maybe that would make up for the philosophical distaste of the license.

Oh man, did I just say that?

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 ...

if OACS plans to move to subverison "eventually" I wouldn't want to move to another rcs "in the meantime."  two migrations is worse than one migration. :)

another thing about perforce -- its win32 client is excellent, but other platforms are pretty much stuck with the commandline.  (A co-worker of mine tried a TK frontend but was unsatified with it.)  I know a lot of the oacs community lives in a unix world by preference so that might not be a good fit.  Nothing against command lines of course, but that's something to consider.

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.

Honestly, I think sticking with CVS for a while isn't going to hurt
anyone. Ron Henderson's CVS document is about all the documentation
that is required, and the system works quite well. Sure, I can
(and often have to) hack diffs by hand at times, but we unix guys
are used to that kind of muckery 😉

Admittedly, I've used CVS for a LONG time, on a LOT of different
projects, but in the end, I think the devil you know is preferable
to the alternatives, until there's a real compelling reason to switch.

As for atomic commits. Yes, they are nice, but I have RARELY been
bitten by this one, even on quite busy CVS repositories. THe branching
model can be a hassle, but if you stick to the "one-tree, with
occasional branches around release time", it does just fine. Really,
everyone should be playing with the release version around
release time anyway.

If anything, Don, I might wait even longer next time before branching,
(perhaps even waiting until you cut the beta code). Developers really
shouldn't be committing to the main development branch during a
release cycle anyway (for everyone's sanity).

Speaking of, is there a local (OpenACS) copy of Ron's CVS document?
It's pretty much required reading for an OACS hacker, and I'd hate to
see it disappear one day...

<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!

I would hate for a Free Software/Open Source project to end up using a non-free source control solution (Bitkeeper or Perforce). That would really suck. As in, REALLY suck.

Subversion I am pretty dang psyched about, though. There's also arch, which is pretty new and...interesting. I haven't played with it yet, but there's a Debian package, so I think I'm gonna. Located at: http://www.regexps.com/#arch

Supposedly handles atomic commits, yada, yada. Comparisions with subversion and CVS at http://www.regexps.com/src/src/arch/=FAQS/features.html

I'll be setting up arch to play around with soon...if it seems really interesting, I'll be sure to let everyone know.

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!

Are you sure they're in the untagged branch?  I've been applying bug fixes to the tagged branch, at least CVS tells me it's the tagged branch (there's a little "Tag OACS-4-5" flag in the CVS lines spewed into your editor by commit).

Subversion has the advantage of upward compatibility with CVS in many regards.  From reading about it, casual users (those who grab sources or only make commits) may not notice any difference at all, which would be great.  The big difference seems to be for those who administer branches and tags and all that.  It's been rationalized and improved in that area.

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?

I'll be merging as soon as I release beta and again after final.

The problem with changing the nightly tarballs to the tagged branch is we'd have to switch back after the final release and that's just a little more sysadmin overhead than I have time to deal with, or anyone else at the moment really.

I don't expect it to be a big deal to see these out of synch for a few days, in practice.

The real answer is to make our software bug free so alpha == beta == release! :)