[cvsnt] Re: CVS Use case

[Matt Schuckmann]

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.