Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Thanks for the reply I appriciate the input. The process you describe is actually pretty close to the process we used to use with our old CM system MKS. The problem I always had with that system is it required a fair amount of custom scripts and nearly crippled the performance of the tool, and I wanted to avoid that with CVS. See below for some more comments: "Merrill Cornish" <merrill.cornish at earthlink.net> wrote in message news:mailman.52.1114192405.20198.cvsnt at cvsnt.org... > 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. :-) > The feature your refering to is the commitid, it can be found the log as follows: ---------------------------- revision 1.2 date: 2005/04/21 23:23:01; author: mschuck; state: Exp; lines: +2 -2; kopt: kv; commitid: 9cc426835d008a9; mergepoint: 1.1.2.1; filename: a.cpp; *** empty log message *** CommitId's can be used in place of tags or revisions by appending a @ or <@ (to refer to the revision before the commit) to the commitid in the -r or -j options for most cvs commands. This could be used to identify just the changes for a Task but how would you use these tags to checkout a functioning build, or create a new release candidate build without a lot of manual labor and/or some custom scripts. > > >>> 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. We don't do nightly builds, it's really not feasable or pudent give the resources necessary to test a build. We do release canadate builds about once or twice a week. Something you said "WHO puts the WORKING_BUILD label on WHAT" gets to the crux of the problem. For various reasons I don't need to get into here, a few privledge people decided what completed Tasks (developers use our bug database system to identify completed Tasks) go into each new release candidate build. Then the release cordinator uses the tool to merge and tag the required file revisions for the new build. The problem I keep running into is the tool can't do the merge and tagging without a fair amount of manual labor or custom scripts which walk the revision tree for all the files. It seems like there ought to be a way to have the tool do most of the work for you. > > >>> 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 > in 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. > It sounds like you had what I've heard called a developer push model, we would like to want to impliment more of a integrator pull model. Thanks again, Matt S.