[cvsnt] CVS Use case

[Merrill Cornish]

Matt,

Here's my 2 cents worth.

>>> 1. When developers submit finished work to the CM system they need to
>>>     identify the changes made with some sort of label, tag, identifier, etc(lets
>>>     call it a Task Label). 

As Glenn said, tags are your friend. :-)

I haven't used the feature, but I believe that CVSNT (and CVS?) provide a special feature such that a well-known pseudo-tag name is automatically applied to the LAST set of files that are committed.  That is, this tag name identifies the tip of all the files taking place in the most recent commit.  The same tag name is used for all commits.

There is also a feature that allows you to attach a new tag of your own naming to all files which currently have another tag name.  So, after each commit for a given task, you (or your macro) could run to attach your "Task Label" to all of the files that have the last-commited-files label.  This would give you tags on just the files associated with a given task, even of several commits when into completing that task.

Others more knowledgable about CVSNT than I will have to tell you what that magic last-commited-files label is--or--tell you that I'm totally confused.  :-)


>>> 2. Developers need to be able to base their work on some minimally tested
>>>     build.
Again, tags.  You would decide on some tag name (e.g., WORKING_BUILD) that would identify all of the file revisions that make up the most recent build "approved" for developer builds.  Your developers would checkout the project based on that tag (WORKING_BUILD, or whatever).  They would them know they have the latest build deemed suitable for development testing whether of not it's the last chronological build.

Of course, the above begs the question of WHO put the WORKING_BUILD lable on WHAT.  The answer to that depends on what the rest of your process looks like.  How do you determine which nightly builds are suitable to developer testing now?

Ideally, all files going into ANY build (nightly, release condidate, released version, whatever) are identified by a suitable tag.  Lets say you've determined Thursday night's build (tagged as, say, NIGHTLY2005_04_22) is unstable, but Wednesday night's (NIGHLTY2005_04_21) is OK.  You would attach (or move) the WORKING_BUILD tag on each file to every file revision that currently has a NIGHTLY2005_04_21 tag.

As each build is done, you (or someone) decides if it is stable enough for development testing.  If so, you move the WORKING_BUILD label to match that build's unique tag.  Your developers blindly extract the WORKING_BUILD files each morning regardless of whether there is a new working build or not.


>>> 3. Developers need to be able to check in unfinished work to the CM system
>>>     for safe keeping without adversely affecting other developers.

When I was Build Master at the Wayne Division of Dresser Industries, we had that problem too.  I solved it by putting a label called BUILD on each file revision that the developer had "released" for use in the system build.  Builds--for whatever purpose--were always done by extracting all source with the BUILD label.

Some of my developers never checked anything back in until everthing was fully tested.  So, for their files, the BUILD label was always on the tip.  Other developers checked in their files each night for safekeeping, regardless of whether they were ready for prime time (or even if they would compile).  For those developers' files, the BUILD label was usually on a reversion several steps below the tip.

Before each build, all developers would send me email telling which revisions or which files they wanted "promoted" to the build.  I would then move the BUILD label on those files accordingly.  Alternately, you could allow the developers to promote their own BUILD tags.


>>>4. As developers work they need to be able to update their working
>>>    environments to the latest tested build, without losing the information of
>>>    what changes are specific to the task they are working on.

CVS is based on the idea of _merging_ updates.  That is, when you tell CVS to "update" a file or files, it will automatically merge the current tip in the repository with whatever is in the developer's local tree.  If the changes in the repository are to lines _other_ than what the developer has changed locally, the merge process is automatic and silent.  If the repository changes conflict with the local changes (e.g., two different changes to the same line(s)), then the conflict is shown to the developer, and the developer has to decide how the local copy if modified.

There is another (and non-default) update mode that will completely replace whatever is in the developer's local tree with what's in the repository, but you have to ask for it specifically.


>>> 5. The release coordinator needs to be able to take a list of approved for
>>>    promotion Tasks and create a new build (we call this a Release Candidate
>>>    Build) which is a conglomeration of the previous build and the changes
>>>   associated with the approved Tasks.

This is just a variation of the BUILD tag I described above.  You could use one tag name (BUILD?) for the nightly builds, and another (REL_CANDIDATE) for the less frequent release candidate builds.  The release coordinator would be responsible for determining which file revisions get the REL_CANDIDATE tag.  After the tag is set, the release coordinator does a build based on the REL_CANDIDATE tag.  

Since you may have several release candidates before you get one you're actually willing to release :-), after a release candidate build is complete, you should probably attach a REL_CANDIDATE_n (which n is the candidate number) to every file that currently has the REL_CANDIDATE tag used the do the release candidate build.

When the release finally does take place, you would attach a RELEASE_3_7_0 (or some such) to all the files that currently have the REL_CANDIDATE_r tags.

There's a lot of taging here.  One file could end up with various Task tags, a WORKING_BUILD tag, many NIGHTLY tags, a BUILD tag, many REL_CANDIDATE_n tags, and a RELEASE_x_y_z tag.  That's fine.  The point is you are alway able to recreate a build later if you have to, and everyone gets to work with generic tag names such as BUILD without having to know a single file revision number.

Good luck,
Merrill