[cvsnt] Re: commit followed by a tag

[Gerhard Fiedler]

> If another developer is working on a different function or fix why would
> they use the same tag, they wouldn't, so there is no common tag and there is
> no reason for the tag to move, so there is no problem. Example Bob is
> working on bug 4343 in the bug database so he tags his files with FIX4343,
> Jan is working on feature 5653 in the requirements database so she tags her
> files with FUNC5653, even if the two overlap there is no common tag. When it
> comes down to promoting the two who ever got done first will have to be
> promoted first or they may have to be promoted together.

I'm not sure I understand you here completely... But for what I understand,
Bo's comments still hold. Cvs is based on differences between successive
revisions. 

Let's say Bob and Jan start working off revision 1.45 of a file, which at
that time was the HEAD revision of that file on the main branch.

Then Bob commits his changes. Since nobody has committed anything yet, HEAD
is still 1.45. So Bob's commit creates revision 1.46, which now becomes
HEAD. He tags it with FIX4343. But this doesn't help much in order to find
out what Bob has changed. To know that, you'd have to have a tag before and
a tag after. Only the tag after doesn't give you the information what has
changed.

Anyway, now Jan is ready to commit. When she tries to commit, the cvs
client will complain that her file is out of date -- because she's still on
revision 1.45, but the current HEAD revision is 1.46 (Bob's commit). She
needs to run an update, which will merge Bob's changes into her file. She
needs to review the merge, make sure everything is still working, and then
commit. If she tags that now with FUNC5653, this tag will include whatever
has been done for the FIX4343 (since that has been committed before).

Especially if Jan had tagged the files before her fix to get a difference
before/after, this difference would include Bob's FIX4343 change.


If I understand your procedure correctly, it was created around some
specific features of your version control system. I think you won't find
many that support this way of doing things (again, if I understood it
correctly). It seems to go contrary to what most version control systems I
know do.

If you really are interested in cvs/cvsnt, I suggest that you read up on
how it works, and on how other people work with it. Then you look at the
/requirements/ of your company (not the current /procedures/), and try to
come up with a procedure to fit the requirements with what cvs has to
offer. I suspect it will be a different procedure than what you have now. 

Gerhard