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.
"Glen Starrett" wrote in message > Tags will work for either. If you really want to know the state of the > project in which the developer was testing, then he should tag the > entire project so that snapshot will be known. How would you make tags work? if you applied the tag across the entire repository how would you make sure that your just tagging the changes associated with the task at hand and not changes associated with other fixes? Further more how would you checkout/create the new build without writing a complicated script. CVSNT doesn't naturally support applying tags to just the changed files, it can be done but isn't encouraged. Furthermore how would you check out/create a build with one or more tasks? > Are you talking about the recommendation on tagging the branchpoint then > each mergepoint (e.g. in the Cederqvist book)? That isn't necessary > with a CVSNT server, see: > > http://www.cvsnt.org/wiki/MergePoint > No I'm not worried about that, imo Merge Points are one of the best things that could have been added to the tool. No I'm worried more about applying 8000 branch tags every time someone starts a new task, and possibly another 8000 tags if you apply a branch point tag which you still need if you want to do a diff between the branch point and the branch tip (or write a script to do it). We can break up the project to a limited amount but not much. Maybe I'm being overly concerned here and it's really no big deal, it looks like it takes about 10 min to tag all these files which isn't too bad. > IMHO, branching is the absolutely BEST way to do what you're talking > about. It is isolated and yet you can still pick up the latest updates. > You can decide from a number of strategies, see: > > http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive) > > That is the Cederqvist book, chapter "Going Out On A Limb (How To Work > With Branches And Survive)" > > Regarding item 5: A possible scenario would be to have the developer > work out on a branch. Before they are ready for final review of the > patch they would update from HEAD and tested themselves (they could have > done so several times before without a problem). When they are ready, > they can create a diff of their branch to HEAD to get the net changes > for that task. Then the release coordinator can do the merging into > HEAD (assuming you will be locking down HEAD for normal devs). > The problem I ran into with this has to do what your talking about. If you merge from the trunk to the branch any files changed on the trunk since the branch point will create new revisions on the branch for those files (I'm calling these files and revisions Merge Artifacts) thus making it appear that these files are part of the task associated with that branch, which in fact isn't the case. Further more when you go to merge the branch back into the trunk all of these Merge Artifacts create Merge Artifacts on the trunk thus making it appear that these files have changed between builds when in fact they haven't. If a branch sits in development for a long time it could collect quite a few Merge Artifacts. Now I could probably write a script to prevent this from happening or we could try to identify these cases and ignore them but that doesn't seem right, how have other people addressed this? > > Lots of people run in ways very similar to what you have described. > CVSNT makes it fairly painless once you get a process in place and > explain it to your developers. > > That's the curx of the problem getting the process in place :) Thanks for the input Matt S.