[cvsnt] Re: commit followed by a tag

[Matt Schuckmann]

Hey, there could even be another option for the commit command, call it
the -b option, which creates a branch with the provided tag name. This was
also an option of ther CM systems I've used.

This fits in nicely with the senario that Gerhard Fiedler suggested, a
senario that I'm drawn to more and more.

All I'm saying is that if you want to use tags or branches or bug id's to
create a subset of your files you should be able to create (or add to) that
subset at the most logical point i.e. when you commit.  If it is a seperate
command to do this you are more likely to forget something or do something
else wrong.

Matt S.

"Matt Schuckmann" <matthew_schuckmann at amat.com> wrote in message
news:cuqqbt$69o$1 at paris.nodomain.org...
>
> "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)
>
>