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