Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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