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.
On Tue, 8 Feb 2005 09:47:50 -0200, Gerhard Fiedler <lists at connectionbrazil.com> wrote: >> 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. > And still one way to go is to start at the common HEAD at the time of both developers being given a bug to fix. Each on his own creates a branch from where they are and work on that branch. When it is time to commit they will not be hindered by any extra commits done by anyone else. So they might even tag their result for future reference at the time of completion. The validation people can then update to that tag and will get exactly what that developer used to fix the bug and can vertify that (each on different branches). When it is all done, in jumps the build master and gets reports of successfully verified fixes to the bugs. What he does now is to merge back both the branches to the (stable) trunk (HEAD), this will merge changes and possibly (but not always mind you) create conflicts. If there are conflicts they have to be examined and sorted out of course. Then he builds a testing version that now contains both fixes, checks that it still is OK and finally commits the fiiles to CVS as the new stable revision. The final step here is to tag everything on trunk with the stable release tag. I think that this is what branches are for and by excluding use of branches you also exclude a large part of teh CVS functionality, and for what? Principle????? /Bo (Bo Berglund, developer in Sweden)