I've thought moderately carefully about the move-devel-to-trunk
issue. I've come to the following conclusions. I would appreciate
comments from anybody who's done this kind of thing before. I've done
a little experimentation but I can't say I'm terribly confident of any
of the analysis yet.
Target date is mostly up to Martin, I guess, once Vin is set up. But
because of the discontinuity imposed by my current practice of
maintaining a temporary devel branch, we should do it fairly soon
after the 21.4 release.
1. Vin can safely make the move of stable/21.1 OFF the trunk at any
time. This is very important. The method is something like
(1) doing a release. This involves making a release tag, say r21-1-16.
(2) make a branch point tag (purely for documentation) as
cvs rtag -r r21-1-16 21_1_moved_to_branch_at_21_1_16 xemacs
cvs rtag -b -r 21_1_moved_to_branch_at_21_1_16 release-21-1 xemacs
(3) moving his workspace on to the branch with
cvs update -r release-21-1
(4) announcing that the stable trunk is dead, and all people using
the stable code base must move to the branch
and except in the event that he deletes his work space (when he
must use a branch tag to check out), henceforth everything goes as
usual for Vin.
Note that people who use release tags rather than the stable
branch to update their trees will notice no difference at all.
Depending on how cautious we are, we could cvs remove all the
files at that point, or after, to forcibly notify people that the
stable branch has moved.
Note: this removal is purely documentation for testers; a little
experimentation with a toy repository has convinced me that unless you
look carefully at cvs log, you can't see any difference between a file
that has been removed and readded and one that was there all along.
Until a file is changed, CVS annotate output is weird, though; the
latest version mentioned in the annotations will be less than working
version. Weird feeling. And all annotations will get the re-added
version, unless you're careful to track back on the old devel branch.
Whether that's a good feature is a debatable point.
So committers and reviewers may notice anomolies, and there will be
some diffculty in tracking things via CVS. But our ChangeLogs are
generally pretty good, and the systematic tagging with each release
(beta and stable) should make recovering old patches fairly easy.
Step (1), (2), and (3) can actually be done retroactively to any
tag, say r21-1-14, and then use
cvs update -j r21-1-14 -j r21-1-16
(the second -j is simply paranoia). I think it does make sense to
do things at "release epoch."
2. At release of 21.4 a node is created at the tip of the
release-21-2 branch, with a branch point tag and the release-21-4
branch. This will have an ugly branch number, but after that
devel will be on the trunk so that should be the worst.
3. The current unstable branch will just die on release of 21.4.
Once the release-21-4 branch is created, we can safely cvs remove
all the files from release-21-2.
Note that CVS history of all of these branches will maintain
continuity.
4. After a decent interval, delete all the files from a working
directory containing the trunk tree, cvs remove them all, then
copy all the files from a temporary-21-5 tree. Then cvs add in
each directory by hand (or script). There doesn't seem to be an
easy way to do this, or to arrange that CVS directly commit a
temporary-21-5 tree to the trunk, but I'll keep looking and
experimenting.
The trunk will show a severe discontinuity in various history
functions. This isn't really that bad, though; maybe a few scripts
would help. The main thing is that we have to remember about stuff on
the temporary devel branch, but even that can be worked around by
merging the release branch to the trunk, then moving all the missing
ChangeLogs to the top (so that they will appear at the top of the
trunk ChangeLog after the temp devel branch is merged to the new
trunk). Add a remark that "these changelogs refer to patches checked
in to the temporary devel branch, you can get at them with cvs diff -r
branch-point -r trunk-move-point", and I think we're covered.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
