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: > 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? > > Glen wrote: > 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. > > No I don't want to only checkout the changed files but I do want to be able to identify what was changed with respect a task, yes if it's on a branch this is pretty easy but what if it's not on a branch? Further more I want to be able to bring the changes from a few "approved" tasks together to create a new Release Candidate build how would one go about doing that? In my mind knowing the complete set files/revisions the developer used to develop and test a task is interesting only if there is a problem with integrating it and in the past this type problem has been rare for us so it's not really all that interesting. >> 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. > > You know what I think your right, when I tested this before I forgot to include the -kk option. When I just retested it I included the -kk option and I didn't have the problem, well the duplicate revision does get created on the branch but not on the trunk cool. Plus while I was testing it this time I noticed the -M option (floating branch) to the tag command, the floating branch is pretty much exactly what I was looking for. I think that floating branches per task are pretty much going to do what I want. Unless any of you know of any peculiarities with floating branches? Thanks Matt S.