RE: Is this possible? <More Info>

[Paul Sander]

Another approach that has been used successfully is to supply some tools
that collect state from the CVS/Entries and CVS/Repository files and store
them in a separate database as a change list to be applied to an existing
baseline.  The system works best if there's a manifest collected for the
baseline, apply the changes to compute a new manifest, and then check out
the contents of the new manifest.

You can see discussion of this by searching the archives of this list for
the string "submit/assemble".

>--- Forwarded mail from address@hidden

>I know it's hard to believe after you sent one email and then a
>clarification, but it's not at all clear what you're asking. Actually, if I
>take it at face value, the question is so trivial I can't understand why you
>would ask it.

>> From: Don Weeks [mailto:address@hidden
>> Sent: Tuesday, December 04, 2001 5:44 PM

>> At 07:17 PM 12/4/2001 -0600, Don Weeks wrote:
>> >Here is what I need to be able to do. (As background, I am used to 
>> >ClearCase and have not had much experience with CVS.) I need 
>> to capture 
>> >the filename and user name for each file committed to a 
>> repository so that 
>> >later, I can use this data to tag exactly that file version 
>> later. This is 

>Um, that's kind of what any version control system does, right? It records
>when each change is committed to each file and who did it.

>> >how I have maintained build baselines in the past and track 
>> exactly which 
>> >files were added. I know I can script against commitinfo but 
>> it looks like 
>> >I will not get enough info on the file to go back and tag it later.

>Huh? First, commitinfo is not the thing to use for this, since a change can
>trigger commitinfo and not be committed. You would want to use loginfo, I
>think. I'm not sure, because I don't know what you want to record that is
>not recorded anyway.

>> A little more info -- What I would be doing is applying an 
>> rtag to files in 
>> the repository. Then I would checkout these files plus those from the 
>> previous baseline to create a new baseline. I would then 
>> build these files. 
>> These files that get rtagged would be those files approved 
>> for this build 
>> and not necessarily the latest versions checked in.  

>There are lots of ways to determine which files have changed since an
>existing tag, and it doesn't require running anything from commitinfo or
>loginfo.
>Probably what you want to do, assuming a module named module_A and a tag
>named prev_build, is something like this:

>cvs -Q rdiff -s -r prev_build module_A

>--- End of forwarded message from address@hidden