[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: capturing all aspects of a commit
From: |
Mark D. Baushke |
Subject: |
Re: capturing all aspects of a commit |
Date: |
Sun, 25 May 2003 08:15:45 -0700 |
Akos Maroy <address@hidden> writes:
> Mark D. Baushke wrote:
> > in the patch. If/when other folks think that such a patch is a useful
>
> if there is a place to vote, put my YES into the vote box :)
Typically, we vote with code and support for the code. In this case, the
code in the patch for commitid is not yet complete as it does not have
test cases written. :-)
> > All that said, there is nothing inherently impossible for you to create
> > some kind of a commitid database as a part of the commitinfo or
> > verifymsg trigger processing (possibly based on the time-of-day and the
> > branch and the userid doing the commit) and have that information used
> > by the loginfo script to record the module, file and version information
> > of each file associated with the commit.
>
> frankly, I don't see how that could be done. as I wrote earlier, for
> each directory of the same commit, the loginfo is called seperately,
> with a different timestamp. thus one can only use heuristics to
> determine what might be a single commit.
The same logic that is used by commit_prep and log_accum to group a
single 'cvs commit' into one log message may be used.
Basically, you need to record the list of directories that are being
processed by the commit_prep step into some reasonable location probably
based on the parent processid of the program running cvs. Typically, the
commit_prep step will also need to use 'cvs -Qn status' on each of the
files to record the version of each file prior to the commit for use by
the loginfo script like log_accum to use later. Then, in log_accum you
make sure to look and see if this is the last directory previously
mentioned by the commit_prep script and if so, it is time to generate
the record that deals with the commit as a whole.
Take a look at how the contrib/commit_prep and contrib/log_accum scripts
work together and you should be able to extend it to generation of a
commitid in the log_accum script for your own purposes.
Good luck,
-- Mark
Re: capturing all aspects of a commit, Kaz Kylheku, 2003/05/25
Re: capturing all aspects of a commit, Ralf S. Engelschall, 2003/05/27