cvs tagging development branch, then merge
Andy Glew
I have fallen into a "rhythm" using CVS:
(1) create an isolated working view for making the changes,
on its own branch, with the appropriate base tag
cvs co -d codebase.enhancement codebase
cd codebase.enhancement
cvs tag enhancement--branch-base
cvs tag -b enhancement--branch
cvs update -r enhancement--branch // to make sticky
...make changes
cvs ci
(2) merging them into the main development branch
cvs co -d codebase.main codebase
cd codebase.main
cvs tag main--enhancement--base
cvs update -j enhancement--branch
...resolve conflicts
cvs update
cvs ci
cvs tag main--enhancement
Thus, when I am doing things in what seems to me to be the
"right" way, I end up with 4 tags:
enhancement--branch
enhancement--branch-base
main--enhancement--base
main--enhancement
// making it easier to determine what changed in the mainline on the addition
Several questions:
Q1: does this procedure seem to be okay?
Q2: I am somewhat concerned by the proliferation of tag names.
At the very least, `cvs log' is becoming really annoying to read.
Does CVS/RCS crash at any point if there are too many tag names?
Q3: the merging step - specifically, the step whereby a tag is given to the
"base" of a changeset - seems to suffer a "window of contention",
in that if somebody checks in files after I have tagged
main--enhancement--base
then they will be picked up by my later update
so that, later, a
cvs diff -r main--enhancement--base -r main--enhancement
will include the intervening edits, as well as my changes
- even if they are made to separate files, no conflicts.
It's pedantic, but it is rather nice to be able to extract just the
changes made for a checkin/merge. Of course, going back to
the branch almost accomplishes that, but not quite.
at the moment, all that I can do when I detect such an intervening
checkin - at the time of update - is to manually move the
`main--enhancement--base' label up when update tells me that
it has pulled in changes.
Q3.1: is there any way to automate this latter "moving up the base"?
Q3.2: I rather doubt that there is a way to prevent such intervening
checkins, given CVS's basic philosophy, but if there is ...?
--
---
Andy "Krazy" Glew, gl...@cs.wisc.edu, UW Madison and Intel.
DISCLAIMER: private posting, not representative of university or Intel.
Please respond by email in addition to replying to newsgroup.
Andy Glew
symbolic labels (ie. "contours" of the codebase), rather than with
individual files?
admin -s sets a state on a per-file basis.
I would like to establish a contour, and then later determine
its state - compiles, works, passes all tests, etc. I suppose
that I can do this by creating new tags, but I have too many dang
tags in my codebase.
Similarly, ideally I would like to be able to say "Give me the
latest fully compiling contour on branch B". Or "give me the
latest fully tested contour on branch B before date D."
Of course, that requires a notion of contours on a branch,
that I do not see in CVS.
The per-file states set with admin -s are not satisfactory,
since such properties are properties of a configuration of
files, not an individual file. E.g. a file may compile with
one version of a header, but not compile with a later
version; it may test completely in one contour, but a later
contour may expose a latent bug.
Joerg Beyer
>
> Is there any way, in CVS, to associate attributes with particular
> symbolic labels (ie. "contours" of the codebase), rather than with
> individual files?
>
> admin -s sets a state on a per-file basis.
>
> I would like to establish a contour, and then later determine
> its state - compiles, works, passes all tests, etc. I suppose
> that I can do this by creating new tags, but I have too many dang
> tags in my codebase.
why not use an old fashioned plain text files, that lists a comment
or state to your labels? You can put this file under CVS control?
keep it small and simple
Joerg
--
Question - why is my good friend the Y2K cobol programmer selling
all his goods, buying gold, guns & food and moving his family to a
place in the mountains? And trying to convince me to do the same?
(Tom ONeil, t_o...@earthling.net)
Derek R. Price
> Is there any way, in CVS, to associate attributes with particular
> symbolic labels (ie. "contours" of the codebase), rather than with
> individual files?
>
[snip]
> Or "give me the
> latest fully tested contour on branch B before date D."
> Of course, that requires a notion of contours on a branch,
> that I do not see in CVS.
Sounds like a tag which can be attched to multiple files would solve the
same problem.
Derek
--
The opinions expressed in this mail are probably mine.
Derek R. Price
> Andy Glew wrote:
>
> > Is there any way, in CVS, to associate attributes with particular
> > symbolic labels (ie. "contours" of the codebase), rather than with
> > individual files?
> >
>
> [snip]
>
> > Or "give me the
> > latest fully tested contour on branch B before date D."
> > Of course, that requires a notion of contours on a branch,
> > that I do not see in CVS.
>
> Sounds like a tag which can be attched to multiple *files* would solve
> the
> same problem.
>
Excuse me. It's too early in the morning. I meant a tag which can be
attached to multiple revisions.
--
The opinions expressed in the posting are probably mine.
Jim Kingdon
> attached to multiple revisions.
Hmm, yes, that would do it.
Trying to make this yet another variation of the tag concept might be
confusing (people get confused enough with the way that branches and
non-branch tags are related in CVS). And I'm not sure you need/want
the ability for a revision to have more than one state or contour or
whatever we are calling it ("experimental", "tested", "stable", &c).
Derek R. Price
> >>>>> "DRP" == Derek R Price writes:
>
> >> Sounds like a tag which can be attched to multiple *files* would solve
> >> the same problem.
> >>
>
> DRP> Excuse me. It's too early in the morning. I meant a tag which can
> DRP> be attached to multiple revisions.
>
> Do you mean branch?
No. Just *arbitrary* multiple revisions. That way, I could tag all my
source after every successful test with say, "TEST-PASSES". Then I could ask
for the last "TEST-PASSES" tag on a branch or before a certain date without
digging through the logs to find a *specific* test-passed tag for each time
the source passes all of the tests.
Derek
Andrey V Khavryutchenko
>>>>> "DRP" == Derek R Price writes:
DRP> Andrey V Khavryutchenko == AVK wrote:
DRP> Excuse me. It's too early in the morning. I meant a tag which can
DRP> be attached to multiple revisions.
>> Do you mean branch?
DRP> No. Just *arbitrary* multiple revisions. That way, I could tag all
DRP> my source after every successful test with say, "TEST-PASSES". Then
DRP> I could ask for the last "TEST-PASSES" tag on a branch or before a
DRP> certain date without digging through the logs to find a *specific*
DRP> test-passed tag for each time the source passes all of the tests.
See my followup on the 'info-cvs' list.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Software is a place where dreams are planted and nightmares harvested ...
a world of werewolves and silver bullets.
-- Brad Cox
Adam Stoller
>
> No. Just *arbitrary* multiple revisions. That way, I could tag all my
> source after every successful test with say, "TEST-PASSES". Then I could ask
> for the last "TEST-PASSES" tag on a branch or before a certain date without
> digging through the logs to find a *specific* test-passed tag for each time
> the source passes all of the tests.
[side-note - don't mean to turn this into a whole new thread]
Have you considered (do you have the option of) moving to a different
version management/SCM system?
I ask because what you're requesting is readily available in ClearCase (and
possibly others) -- though I admit, that's a large jump to take just for one
feature. However, if there are other features you find lacking, it might be
worth researching alternative tools (assuming you have the ability to lead
the development staff to something different -- which is *not* often the
case)
Just a thought,
--fish
John Minnihan
> "Derek R. Price" wrote:
>
> Excuse me. It's too early in the morning. I meant a tag which can be
> attached to multiple revisions.
A variation of the implementation of a "TEST-PASSED" <permanent> branch is
the notion of floating your sticky-tag TEST-PASSED w/o creating a branch.
This is arguably more work than simply creating a TEST-PASSED branch and
working there, but at least has the benefit of avoiding branch joins.
Simply put, you may <artificially> float the sticky tag TEST-PASSED to new
revisions this way:
1. Identify the sources
2. Create a CVS work dir
3. Tag the sources using
cvs tag TEST-PASSED
3. Identify & test new sources <= This presumes someone else has committed
new revisions
4. Remove tag from all modified source(s) using
cvs tag -d TEST-PASSED <modified file name(s)>
This will remove the tag ONLY from the modified files, leaving
unmodified files alone
5. Place the tag on the modified files which have been posted to the
repository
cvs tag TEST-PASSED <modified file name(s)>
This will tag ONLY the modified files, leaving unmodified files
alone
6. Update workdir using
cvs update -r TEST-PASSED
7. Iterate
This is somewhat capricious, in that you are violating the protocol of "once
labeled, always labeled". But, this may solve your problem when no other
technique will. If you can operate in isolation from the trunk, the use of
a branch named TEST-PASSED is easier. Look at the info-cvs list for a very
good presentation of the branch technique by Andrey Khavryutchenko.
I have tested this & it works. With a few minutes of scripting, you could
float your label to new revisions easily.
--
John Minnihan
Greensfelder Technology Corp.
Software Process Improvements
http://www.greensfeldertech.com
303-204-8811
John Minnihan
John Minnihan wrote:
> 1. Identify the sources
> 2. Create a CVS work dir
> 3. Tag the sources using
> cvs tag TEST-PASSED
> 3. Identify & test new sources <= This presumes someone else has committed
> new revisions
> 4. Remove tag from all modified source(s) using
> cvs tag -d TEST-PASSED <modified file name(s)>
> This will remove the tag ONLY from the modified files, leaving
> unmodified files alone
cvs update
This brings in the modified sources that currently don't have the
tag
<run the tests - the whole point, right?!>
> 5. Place the tag on the modified files which have been posted to the
> repository
> cvs tag TEST-PASSED <modified file name(s)>
> This will tag ONLY the modified files, leaving unmodified files alone
> 6. Update workdir using
> cvs update -r TEST-PASSED
> 7. Iterate
>
----------------------------------------------------------------------------------------------
John Minnihan
Greensfelder Technology Corp.
jbm...@NOSPAM.greensfeldertech.com
http://www.greensfeldertech.com 303-903-6130
----------------------------------------------------------------------------------------------
"What can we do to make this better, faster or cheaper? Can our software help
us get there?"