Re: how to checkout partly tagged source?

[Eric Siegerman]

On Wed, Apr 10, 2002 at 05:45:11PM +0200, Jens Fassbender wrote:
> I added a tag only to some files of my source code, e.g. to identify
> files changed within the same development step:
>
> [there's a baseline tagged with REL_1; the tag TAG_1 was
> applied only to files changed since REL_1, not to the entire
> source base]

The way not to get into this situation in the first place is to
tag the entire source tree, NOT just the files you've changed.
In CVS, a (release) tag labels a snapshot of the source base at a
particular point in time, so that you can reconstruct it later
(i.e. exactly what you're now trying to do).  Tags are not
intended to label "what changed between time A and time B", which
is how you seem to have used them.

CVS doesn't really have a good way to do the latter; it doesn't
provide the concept of a change set.  The best you can do is to
tag the entire source tree before making a round of changes, and
then again after.  Then you can use "cvs diff" or "cvs log" to
look at the differences between the two tags.  As well, at least
one of the Web GUIs sort-of adds change sets (but only intuited
after the fact; I imagine it figures out which deltas comprise a
set by looking for ones with the same timestamp and log message).


Now, recovery from your current situation.

One possibility might be something like this.  Try it on a COPY
of the repo at first, in case it messes things up further!
        cvs tag -rREL_1 TAG_1

N.B.: *WITHOUT* either -f or -F options.  The idea is to apply
TAG_1 to the revision that's already tagged with REL_1, but only
for files which don't already contain TAG_1.  Any existing
TAG_1's are to be left alone.

I can't remember whether CVS will do that, or instead abort with
an error message the first time it finds a file already
containing TAG_1.  If the latter, maybe you could hack together a
temporary version of CVS that doesn't die in this case, but
simply emits a warning and plows on.

Or, something like this might work:
        cvs update -rREL_1
        cvs -n update -rTAG_1 >fixes
        sed -n 's/^U //p' <fixes | xargs cvs update -rTAG_1

Notes:
  - The last two commands constitute a logical pipeline, but I'm
    guessing that the intermediate file "fixes" is necessary due
    to locking issues between the "cvs" processes at either end

  - "fixes" will also contain "R" lines for the files that
    haven't been tagged with TAG_1.  The sed command filters
    those out (courtesy of the "-n" and the final "p"), since the
    whole point of this exercise is to avoid updating those files
    to (the nonexistent) TAG_1.

The only way that's guaranteed to work is also the most painful:
stitch together the version you want, basically one file a time,
using a bunch of "cvs update -r1.xxx foo.c" commands.  Of course
you can take advantage of any tags that'll make the job easier,
and possibly -D options as well.

Once you've reconstructed the version you want, tag it (all of it)
with:
        cvs tag TAG_1_FIXED

You could also reuse TAG_1, of course, by adding a -F option; but
that'd be very unwise, since it would trash information that
might be essential if you've made any mistakes in your
reconstruction.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
        - Anonymous