[cvsnt] Re: commit followed by a tag

[Gerhard Fiedler]

Matt Schuckmann wrote:

>> When someone checks out such a tag, the result is of a very limited use.
>> You can't build it because all the other files are missing. So you can't
>> even verify that it works. If you check out the other files to build it,
>> you don't know which revision of the other files to get. The tagged files
>> usually depend on interfaces in the other files, and if these change, the
>> tagged files would have to change, too. This is why Bo said that a tag
>> usually needs to tag everything that's necessary for a build, because even
>> though you maybe changed only three files, the changes make only sense in
>> the context of the other thirty files as they were at the time you changed
>> the files.
> 
> I think that it would be a safe assumption to first checkout, or update to,
> the last tagged build before the tagged subset of files, this has worked
> just fine for us for 2 years. Or maybe you don't really care, maybe the
> changes are self contained and you don't really care what version the rest
> files are at just so long as they work.

> If your working in the paradigm I described before the tag before the
> changes would be the last build tag or the last fix tag. 

This is not how I understood your process so far. You said that you wanted
the changes labeled because it gets decided at some point whether they go
into the next stable release or not.

Say you have TAGGED_BUILD_15. Then you implement FIX145. Then someone
creates the next TAGGED_BUILD_16 /without/ FIX145, for whatever reason.
Then someone wants to verify FIX145, checks out TAGGED_BUILD_16 (the last
tagged build, that's the assumption you gave) and FIX145 -- and boom, it
doesn't work because something in TAGGED_BUILD_16 messes with something
FIX145 needs.

So you need additional information that FIX145 depends on TAGGED_BUILD_15
and not on the /last/ tagged build. So why not tag the whole bunch of files
with FIX145?

It seems to me that you guys created a procedure based on some available
and created features of a version system. Now you want to use a different
one, emulating the same behavior. Sometimes that works, but IME usually you
need to adapt procedures to the tool you are using. No use in fighting the
tool -- if it isn't close enough, get a different one.


> Oh and wouldn't it be cool if you could if you could give checkout or update
> several tags and it could automatically figure out what set of file
> revisions is the most update given those tags.

If you have a somewhat consistent tagging procedure, these tags have a
sequence in time. If you update to them in the correct sequence order, you
get what you want. 

cvs up -r BLD1
cvs up -r FIX3

However, if you didn't tag the whole project with these tags, you now have
some files on BLD1 and others on FIX3.


>> This could be different if cvs had the option to assign a single symbol
>> to various revisions of a file. ...

> Hey you finally got it this is exactly what I want and yes CVS can almost do
> this it just takes a minimum of two commands to do it, maybe 3 because I
> don't think that commit displays the new revision numbers added.

Not really, if I understand you correctly, because cvs can't assign a
single tag to multiple revisions. That's not the way tags work in cvs.

> Why not just add a couple of options to the commit command and make it 1
> command, like everybody else does. It's not anything ground breakingly new.

It's not, but it's also nothing that's really worthwhile for the way cvs
tags work (or better, for the way I understand them to work).

> Forget why I want the tag there and what I'm going to do with it. You seem
> to be hung up on the way your used to working with CVS.

No, I don't think so. I just would like to understand what could be done
with this feature that couldn't be done better otherwise. You said above
"this is exactly what I want", but that means that cvs is not for you. You
can't tag multiple revisions of a file with the same tag, which would be
necessary for that scenario I described and that you said is exactly what
you want.

Forget what you _did_ so far with what you call "tags". It seems you need
to understand what tags are /in cvs/. If I understand you correctly (and
you seemed to have confirmed that by saying "this is exactly what I want"),
you don't want cvs tags, you want something else. 


> Actually the first time you check in (commit) is the point at which you
> really start to diverge from the stable build and you may or may not revisit
> that file. 

I start to diverge (in my head) the moment I start working on a feature. I
know I will change _something_, and thus I create a branch.

> If you do you just move the tag/label/symbol/bugid up to the next
> revision, it's sort of like a floating label (but not really). Further more
> you may decide to abandon the changes before ever commiting so then in your
> senario you've got a dead branch/tag sitting out there taking up space. 

This shouldn't happen too often. If it does, there's probably something
wrong in the feature/fix assignment process.

> Why go through the extra work to create a tag/branch across the entire
> repository when all you really care about is just a few files.

Because these files depend on the others. You create an alternative build,
not just a set of files you worked on. (See the top of this message.)


Much of the confusion in this discussion seems to stem from the fact that
your build process makes a number of assumptions that were not clearly
described. As in that a fix compiles with whatever other files are around.
Or as in that the fix lives in the context of the last stable build, but
then you say that it may depend on other fixes not in the last stable build
(with is something different already) and you also say that the purpose of
the whole thing is to select what goes into the next stable build, so a fix
might not go in, which then makes it dependent not on the last stable build
but the one before (or even earlier). Figuring all that out depends on a
whole lot of additional infrastructure and documentation -- or it worked by
chance, or the problems simply got worked over without ever noticing them
explicitly.
 
Gerhard