[cvsnt] Re: commit followed by a tag

[Bo Berglund]

On Fri, 11 Feb 2005 11:32:01 -0800, "Matt Schuckmann"
<matthew_schuckmann at amat.com> wrote:

>This whole discussion has brought us back to my origonal point, why can't
>you tag when you commit? Tony said it doesn't make sense, he also said that
>to use tags to discribe change sets is incorrect.
>
>However, you and Bo have both descirbed scenarios where change sets are
>described by tags and in those cases it makes perfect sense to tag the files
>your commiting at the point that you commit, when things are fresh in your
>mind and the chance of forgetting something is small. Tags can be moved up
>the tree as additional revisions for a fix are checked in  and tags don't
>have to span the whole project.
>

Not really so....
Your supposition is that no commit is ever made without it being a
full solution to the problem at hand. But this is not how many groups
use CVS, we are not doing thta at all. Instead we enforce that
developers commit their code at the end of the day so that it all is
in safe keeping on the server and will be backed up. In this case it
makes no sense tagging enything until you are done.
Furthermore, if tagging occurs automatically on commit then only the
committed file gets the tag and this is clearly wrong! Tags are mainly
used to tie together all files in a group that together compries the
time snapshot for a certain property (like a release or bugfix). So
the tag should encompass *all* files needed to build that particular
version, not only the single or few files that have been committed.

I think it is clearly WRONG to tag automatically.

If you really want to do this anyway you have always the possibility
to program the loginfo script on the server to do whatever you need,
for example setting up the condition that will be used by the
postcommit script later on. Postcommit can for example issue a tag
command all by itself and make that procedure work for you.


/Bo
(Bo Berglund, developer in Sweden)