Forum OpenACS Q&A: Getting ready for beta - tagging and branching CVS
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!
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
$ 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.
This is the danger, I guess, forgetting to switch to the right place if you flip-flop.
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.
Well, at least those last things aren't due to CVS!
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.
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!
Bitkeeper and Perforce are both superior to CVS, but not to what Subversion will become when it grows up.
I do plan to take a look at subversion though when it comes out.
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.
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?
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...
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?
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 ...
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.
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.
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...
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.
(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!
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.
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?
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! :)