Andy Jones <[EMAIL PROTECTED]> 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
