Kagami Project Notes

Things I've have learned (again) when testing Kagami with CVS

• Each sub-directory involved in a cvs commit appears to trigger scripts as different commits
• loginfo has two different ways of sending the list of files depending on what version of CVS is running on the server
  • prior to 1.12.6 you could list "%{sVv} and on the command line would appear:

    module file1,1.1,1.2 file2,1.3,1.4

  • 1.12.6+ you would need to list "%p %{sVv}" and CVS will ensure that each item is presented as seperate arguments:

    module file1 1.1 1.2 file2 1.3 1.4

• running rlog on every file listed is very tedious and can quickly bog a CVS server down so Kagami has the ability to split the loginfo and rlog steps up
• when the loginfo trigger script reports a file as been deleted you cannot run rlog on the path given because the file has already been removed - you need to append Attic to the repository/module path as that is where CVS stores deleted files.

Thoughts on how to extract from CVS the notion of a batch or group of commits

Update: can it be that the only sure way to gather or batch commits is to compare the message? After looking at the methods I list below and doing some other thinking based on date/time stamp it may be. I need to research how cvs2cl does it.

Update: while reading the cvs2cl site they mentioned cvsps - it's a tool to generate a patchset! Could be exactly what is needed.

If you just take the output from rlog (the most common way to get revision information for a CVS item) you only see the history for that file for it's lifetime. You don't see across the whole repository or even within the same directory.

Example of rlog:

bear@opus:~/temp/usr/local/cvsrep/chandler$ rlog run_tests.py,v 

RCS file: run_tests.py,v
Working file: run_tests.py
head: 1.1
branch:
locks: strict
access list:
symbolic names:
        CHANDLER_DEMO_D_2005: 1.1.0.4
        CHECKPOINT_20050509: 1.1
        CHECKPOINT_20050502: 1.1
        CHECKPOINT_20050425: 1.1
        CHANDLER_20050425: 1.1
        CHECKPOINT_20050418: 1.1
        CHANDLER_0_5_02: 1.1
        CHANDLER_0_5_01: 1.1
        CHANDLER_0_5: 1.1
        CHANDLER_0_4_09: 1.1
        CHANDLER_0_5_BRANCH: 1.1.0.2
        CHANDLER_0_5_BASE: 1.1
        CHANDLER_0_4_08: 1.1
        CHANDLER_0_4_07: 1.1
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
----------------------------
revision 1.1
date: 2005/02/02 17:56:33;  author: pje;  state: Exp;
Scripts to run and/or profile unit tests, and test suite definitions for
repository.tests and application.tests.  Use 'RunPython run_tests.py'
or 'RunPython profile_tests.py' to view the documentation.
=============================================================================

You can see that each revision entry has a date/time stamp and one thought would be that you can compare other entries for the same or similiar date/time stamps but then you need to worry about how long a single commit took and set thresholds for the difference.

Another option is to make use of the CVSROOT/history file, this file contains an entry for each time cvsrep was run. Below is the history entry for the run_tests.py revision 1.1 event:

A42011451|pje||chandler|1.1|run_tests.py

Here is a sample of a single CVS commit and how it was stored in the history file:

bear@opus:~/temp/usr/local/cvsrep/chandler$ grep M42812a9a ../CVSROOT/history 
M42812a9a|stearns||chandler/parcels/osaf/framework/blocks|1.16|Trunk.py
M42812a9a|stearns||chandler/parcels/osaf/framework/blocks|1.166|parcel.xml
M42812a9a|stearns||chandler/parcels/osaf/framework/blocks/detail|1.117|Detail.py
M42812a9a|stearns||chandler/parcels/osaf/framework/blocks/detail|1.76|parcel.xml

The first field contains a unique ID that can be used to group multiple CVS events. Here is the revision information for Detail.py and parcel.xml -- not all of it, but enough to prove that both items have the same date/time stamp.

revision 1.117
date: 2005/05/10 21:41:46;  author: stearns;  state: Exp;  lines: +4 -2
More work on fonts in the detail view, with spillover into the summary view:
- Scale font requests by the default font on the current platform (so if the characterStyle.fontSize says "12 point", use the sy
stem font point size, which happens to be 11 point on Mac and 8 point on the PC. A proportionally larger or smaller characterSty
le.fontSize will produce a proportionally larger or smaller font.
- Specify that the summary view and its header use the default font size for the platform (it was defaulting to something a litt
le bigger on Mac).
- Specify that the popup controls in the detail view use the default font.
- (The calendar view and the sidebar weren't touched for this.)
- (The detail view is still using explicit layout; it'll eventually be automatic based on text size, but isn't yet. This is true
 for label widths, too - I've made them narrower now that the fonts on all platforms are a bit smaller.)

Fix bug 2414: Font specs produce inconsistent sizes across platforms

Also, a few minor cleanups, and more debugging toward fixing 2857 (crash on Mac when clicking allDay).
----------------------------

----------------------------
revision 1.76
date: 2005/05/10 21:41:46;  author: stearns;  state: Exp;  lines: +37 -115
More work on fonts in the detail view, with spillover into the summary view:
- Scale font requests by the default font on the current platform (so if the characterStyle.fontSize says "12 point", use the sy
stem font point size, which happens to be 11 point on Mac and 8 point on the PC. A proportionally larger or smaller characterSty
le.fontSize will produce a proportionally larger or smaller font.
- Specify that the summary view and its header use the default font size for the platform (it was defaulting to something a litt
le bigger on Mac).
- Specify that the popup controls in the detail view use the default font.
- (The calendar view and the sidebar weren't touched for this.)
- (The detail view is still using explicit layout; it'll eventually be automatic based on text size, but isn't yet. This is true
 for label widths, too - I've made them narrower now that the fonts on all platforms are a bit smaller.)

Fix bug 2414: Font specs produce inconsistent sizes across platforms

Also, a few minor cleanups, and more debugging toward fixing 2857 (crash on Mac when clicking allDay).
----------------------------

You can see that they share the same commit message also.

It may turn out that a combination of the two methods needs to be used. Parsing the CVSROOT/history file will allow us to group different revision entries into the same SVN commit and receiving the rlog output during post commit will give us per-transaction information.

-- MikeT - 07 Jun 2006