[cvsnt] Re: commit followed by a tag

Matt Schuckmann matthew_schuckmann at amat.com
Mon Feb 14 18:23:54 GMT 2005


"Bo Berglund" <bo.berglund at telia.com> wrote in message
news:ctgq01d4717kealodtr9fc0v1094gdtbub at 4ax.com...
> 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.

I never said that, in fact I too would incourage people to commit early and
often, several times a day if it makes sense, for all the same reasons that
you listed.
Tags can be moved, or so it says so in the documentation (-F option of the
tag command). So why can't there be an option to apply a tag to all
revisions being commited and another opiton (say -F) to force reassignment
of that tag if it already exists on that file. In this way the tag would
continuosly represent the head the work on that function or fix. This has
nothing to do with the whole process I described before, it's applicable in
many ways and it's a time saver and helps to prevent mistakes.


> 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 why can't tags be used to tie together a group of files that represent a
fix or feature. Or hell just to help you keep track of what your working on.
Nothing says that they have to span the entire project.


> 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.

You seem to be stuck on the consept that tags are only usefull for
indentifying a complete build, I would argue that that's not true. They can
also be use full for indentifying a subset of the build that you may want to
keep track of, or be able to checkout easily, etc.

I never said automatically, the developer gets to chose if he wants to apply
the tag, it would be an option for the commit command something like:

cvs commit -m"" -t NewTAG -F

The -t option applyes the "NewTAG" tag to all the files being commited.
The -F option forces the "NewTAG" tag to move to the new revision if it
already exists on a previous revision.
If you've modified 3 files in your sandbox then 3 files will have the tag
NewTAG. There maybe other files in the repository that already have the
"NewTAG", perhaps files pertaining to the "NewTAG" work that were checked in
the previous day.

Like I said I've seen this exact feature in several other CM systems only
they called tags labels.

Why doesn't this make sense? you just applying a place holder to some files
in the repository to help you keep track of your set of changes, and perhaps
help someone else indentify exactly what goes into your work. And your doing
at them most convenent, and least error prone time.

The bug id comes close to doing this but you can't check out by bug id, you
can't tag by bug id, you can't manage the bug id's in anyway, other than
just creating them, and it's so new that no one supports them.

>
> 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.
>

How would you get the tag name from the command line to the script?

>
> /Bo
> (Bo Berglund, developer in Sweden)





More information about the cvsnt mailing list