[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]