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.
Matt Schuckmann wrote: > "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? You don't actually want to only check out the files changed on a branch -- you want the full set the developer is working from. That way you can checkout that tag and build to see exactly what the developer was testing against. You could create a script that would tag just changed files on that branch (e.g. rlog -r branch. | grep...), but I'm not sure that's what you're really looking for. > 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? I'm not sure what is causing that to happen, but if you can come up with a repeatable case to reproduce this and report it then I'm certain that Tony can get it fixed (He's always been very good about that sort of thing). The only time I would expect a "null delta" to be committed with a merge operation is if there was a keyword change and then it makes sense. -- Glen Starrett