[3007] in Release_Engineering
Source Tree meeting
daemon@ATHENA.MIT.EDU (Richard Basch)
Fri Apr 16 10:56:15 1993
Date: Fri, 16 Apr 1993 10:56:10 -0400
To: builder@MIT.EDU
Cc: tjm@MIT.EDU, rel-eng@MIT.EDU
From: "Richard Basch" <basch@MIT.EDU>
There wasn't critical mass...
What is your availability for:
Tue 4/27 10:30-12
Thu 4/29 3-4:30
Fri 4/30 anytime
The people who need to be there: mar, vrt, miki, cfields, probe.
Rough agenda:
- Quick discussion of problems
- Agree on the constraints
- Hash out possible solutions
- Discuss issues, next steps, etc.
Hopefully, this will be straight-forward, but I suspect the constraints
and issues sections will re-surface a few times during the meeting.
The following is a (poor) illustration of my proposed solution
--------------------------------------------------------------
rel.bld --> rel.src rcs (CVS tree)
PORT
bld -> src --> rel.src
The release sources will frequently be updated from the CVS tree, so
that people are able to view /source and see what is currently being
integrated into the "next release".
Checkins would be "disallowed" from anything other than rel.src while a
field release is being built (this includes such things as the field
release of 7.5B for the RISC/6000). Evaluation port builds are probably
not as major of a concern to archive exactly.
The reason for the separate build and source volumes for the port is so
that the build volume can easily be blown away in bulk. Another reason
is so that when the port is finally checked-in, everything can be
tagged. The sources for a port build would normally be links to the
release sources. Whenever a change needs to be made that is basically a
function of the port (rather than fixing obvious bugs or problems with
the release), one would checkout that portion of the tree and break the
links (normal bug-fixes, etc. can be fixed immediately in the release
sources).
Issues:
- Checkout must preserve the "read" acl from the CVS tree; it must edit
the system:anyuser bits and all other "rl" related bits in the tree
in which the sources are being checked-out.
- Since we sometimes remove obsolete modules from the source tree, we
need to implement a "delete" operation which will keep the RCS history
around should you want to check-out the old version of a tree. One
possible way of implementing this is to place a "DELETE" RCS tag on
the deleted item and when a check-out is run, if no version is
specified and the "head" has the DELETE tag, ignore it. For
cleanliness, CVS should prune empty directories during the checkout.
The constraints I see are:
- Difficult to track the history of the source (no RCS tags)
- Difficult to effect multiple patch releases (need to recopy the
sources, change various mountpoints to have the new volume names,
etc... a cell management headache).
- Difficult for multiple ports to take place concurrently (close to
impossible, since rcsmerge is not in our daily repetoire). CVS is
basically a friendlier concurrency layer on top of RCS, but we
could theoretically implement our solution by strict RCS practices.
- Copying the source trees automatically gets us the RCS histories for
all the previous revisions. Again, this can be solved, but it does
require lots of cell management, per release or integration. During
each one of these integrations, NO CHANGES may take place, and this
can take a few days.
Tasks to complete:
- Setup a common area for the CVS binaries and related support utilities
(new RCS, GNU diff, etc).
- Extend CVS as necessary to implement the semantics that we require.
- Convert the source tree on a mutually agreed upon schedule.
Of course, the above makes several assumptions about buy-in and assumes
that we have hashed this out in greater detail than I have presented
here. It is only one possible solution, but one that I thought would be
best to present to everyone since I have a little more than a simple
conception. Other solutions and ideas welcome. In the past two days, I
have received several mail messages from several people, including some
pointers to alternate software. I will try to collate all of this for
people to peruse.
-Richard
