[1766] in NetBSD-Development
Re: sipb-source-commit: third/mh/conf MH.linux
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Sep 5 10:52:27 1998
To: Salvatore Valente <svalente@MIT.EDU>
Cc: nathanw@MIT.EDU, sipb-source-commits@MIT.EDU, sipb-athena@MIT.EDU
In-Reply-To: Your message of "Sat, 05 Sep 1998 04:55:23 EDT."
<199809050855.EAA28231@StarbaseZero.ne.mediaone.net>
Date: Sat, 05 Sep 1998 10:52:16 EDT
From: Greg Hudson <ghudson@MIT.EDU>
I'll attempt to answer for Nathan here for the sake of timeliness.
Your last message went to sipb-source-commits and not linux-dev; I
added sipb-athena to the cc list since sipb-source-commits isn't a
discussion forum (and Nathan probably shouldn't have cc'd it on his
initial reply).
How to get approval for pulling something up to the sipb-athena-8_2
branch is an interesting question. Traditionally, Nathan made that
decision unilaterally as the (de facto) NetBSD-Athena release
engineer. Likewise, I've made that decision unilaterally for the
Athena tree. When you have two release engineers for a branch, they
might want to communicate somehow. There are a few options here (no
communication, private communication, sipb-source-reviewers,
sipb-athena, a new list, whatever); I don't want to try to make the
decision for other people. Developers who are not release engineers
should request pullups to the release on sipb-source-reviewers, of
course.
From a technical perspective, changes which should go into
sipb-athena-8.2 fall into three categories:
1. Changes which were made in the main Athena source tree, for an
existing file we haven't modified
In this case, the change should first be imported into the sipb-athena
tree in the way documented in /mit/source-sipb/doc/sipb. At that
point, there will be a revision (say, 1.1.1.3) in sipb-athena with the
change on it. One could then pull it up to sipb-athena-8.2 with
something like:
cd /var/tmp
cvs co -kk -r sipb-athena-8_2 path/to/file
cd path/to
cvs update -j 1.1.1.2 -j 1.1.1.3 file
# If this is not a simple change (e.g. if revision 1.1.1.2 is
# being skipped over), use cvs diff to make sure something
# sane happened.
cvs ci
Pull up changes from rev 1.1.1.3 to 8.2 branch.
(Brief description of change here.)
2. Changes which were made in the main Athena source tree, for an
existing file we have modified
Just as in (1), we first need to import the change into sipb-athena.
This gets it into some version like 1.1.1.3 on the vendor branch, but
since it's a modified file, there is the extra step of propagating the
change into the mainline. You do that in standard cvs fashion,
something like:
cd /var/tmp
cvs co -kk path/to/file
cd path/to
cvs update -j 1.1.1.2 -j 1.1.1.3 file
# Check that something sane happened, if you think there might
# be overlapping changes.
cvs ci -m "Merge local changes."
This gets the change into a revision like 1.3. Then you pull it up to
the branch with a procedure just like in (1):
cd /var/tmp
cvs co -kk -r sipb-athena-8_2 path/to/file
cd path/to
cvs update -j 1.2 -j 1.3 file
# Check if something sane happened, same as in (1).
cvs ci
Pull up changes from rev 1.3 to 8.2 branch.
(Brief description of change here.)
3. Changes which were made in SIPB-Athena, to an existing file
In this case, the change should first be committed to the mainline of
sipb-athena, of course. This gets it into a revision like 1.3. Then
you pull it up to the branch the same way as in (2).
4. Cases like (1)-(3), but involving multiple sets of changes
Feel free to pull up multiple changes to the 8.2 branch at once.
5. Changes involving the addition and deletion of files, either to the
main Athena tree or to sipb-athena
A little more CVS clue is needed here, and I don't have the energy
just now to enumerate all four cases and explain how to deal with
them. If this comes up and it isn't obvious, ask Nathan or I for
help.
Sal wrote:
> Can I use the patch command or emacs, or am I expected to use "cvs
> update -j"?
As you've probably gathered by now, "cvs update -j" can be used
flexibly enough for our purposes. If some other method has achieved
exactly the same result as "cvs update -j", then nobody can tell the
difference ("cvs update -j" doesn't do any bookkeeping; it just edits
the file in the working directory) so it's clearly just as good. But
following the procedure is more reliable.
Note the use of "-kk" in my sample checkout commands. Doing your
merges in a directory checked out with -kk will make RCS tag conflicts
much less frequent (only $Log$ will get in the way). Don't do builds
(except for testing) out of such a source directory, though, since the
resulting object files will have no RCS tag information.
