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 [EMAIL PROTECTED] >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:[EMAIL PROTECTED]] >> 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
