Re: cvs tag: some slightly counterintuitive behaviour

[Sergei Organov]

Andy Jones <address@hidden> writes:
> Jason Carucci>>>
[...]
> Derek Price>>>
> >The work-around, and a pretty straight-forward one I should think, is to
> >commit your changes before tagging.
> 
> No, no. I don't want to remove the files. I just want to not tag them. Now
> it looks like I will have to tag the whole sandbox and then untag a list of
> about 30 files - not fun.

You actually have been given a good advice, I believe: never tag directory
with uncommitted changes *for release*. I think CVS behavior is fine as it
makes it hard to do a wrong thing. It seems that what you actually need at
this point of development is to create a release branch. You then
remove/resurrect files on the branch as needed until you decide what the
release is, and only then finally tag the current state of the branch as
release.

> 
> Is it really a pain to change (assuming it should be changed)?

I'm strictly against such a change as current useful behavior will be lost.
When you change something in the working directory it's useful to be able to
tag (just before commit) the version you've started with to be able to return
to it later or to generate diffs against the tag. That's exactly what CVS
currently does.

> Modified files shouldn't be a problem - just ignore them, as now. Anyone who
> doesn't like this behaviour should be doing cvs tag -c anyway...

No, -c is to *deny* tagging if there are uncommitted changes, and the current
behavior without -c is different and useful. 

-- 
Sergei.