Re: Using CVS for package development
> I have had a very quick look at the aegis README. It has a
> baseline (main trunk in CVS; no mention of multiple independent
> branches and back merging that I could see).
It relies on RCS or CVS for its version control, so you get access to most if
not all the features of those (or at least I think you do --- been a long time
since I used it)
It does allow multiple people to work on the same thing, but only one baseline
exists. You can only get stuff into the baseline if it doesn't break
anything, its like the unstable vs. stable split, but with automated checks.
> It implements a per
> change test rquirement (thought: what tests? that the package build?
> could be done with a commitinfo script in CVS).
This can be waived, but many tests would be fairly simple to write, and should
really be done.
The basic idea is that you write a script that fails with the old version, and
succeeds with the new, so that the script tests for the bug-fix or feature
that has just been introduced. Since the tests get run for every change, it
should elliminate repeat occurences of the same bug.
The other thing that it does, that people were talking about is administer the
peer review thing, by mailing a tester, and requiring an approval before
letting the change into the baseline.
I can't see it working for ongoing unstable development because it would be
too severe a bottleneck, but it might be useful for keeping stable stable, and
the accumulated tests should be useful when we next do a freeze.
> For the most part it fits in the same niche as CVS. I just
> wonder how easy is it to come up with regression tests for changes
> that are made, and whether they will be valid at the next change.
> Seems more, umm, restrictive than CVS, but I should really
> download the source to see.
I think so --- even if you don't use it, the ideas should be applicable.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .