Re: [ANNOUNCE] cvsps support for parsing BK->CVS kernel tree logs

[David Mansfield <david@cobite.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3222 bytes --]

> what about the deleted files? should we teach cvsps how to diff the old
> revision fetched with cvs up -p against /dev/null to make a completely
> coherent patch?

It's already supposed to work that way :-(  See below.

> this is with 2.4
> 
> Directing PatchSet 2742 to file ../patches-2.4//2742.patch
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'
> cvs [update aborted]: no such directory `drivers/usb/hcd'

This has been fixed already in 2.0b5 (on www.cobite.com/cvsps website).  
It was all working fine if you had a checked out tree.  But doesn't work
to use 'update -p' if the sub-directory isn't checked out (update -p is
what is used in your version).

The new code uses 'cvs co -p -r x.y repository/file' which works fine.
The patches that are generated by '-g' now need 'patch -p1' to be applied
inside the working directory.

> I also wonder if cvsps is so accurate also w/o the --bkcvs option (i.e.
> w/o atomic commits from bk). are the dates guaranteed to be the same for
> all files w/ a normal cvs tree?

No.  On a normal CVS repository, and without the --bkcvs, a heuristic is
used to recreate a 'commit'.  The commit must have the same author, the
same message and the time of commit must be within a fuzz-factor number of
seconds (default 300, settable via the -z option).  The reason the
fuzz-factor is needed is that a commit over a slow link, or a very large
commit in general can take a lot of time, and the log time will vary for
each file committed.

It actually works quite well.

> what about the -f option? why can't I use it at the same time with -r?
> Can I use multiple -f at the same time? That is getting very cool and so
> useful.

Oops.  You found a bug.  See the attached patch against 2.0b5 (should work
against any recent version).  By design though, all of the 'filter'
options can be combined.  Also by design, you cannot specify multiple
instances of any option (except -d and -r, where the first and second
instance have special meaning - start vs end).

> Would also be nice to export the API of the cvsps internals to python
> (i.e. to allow to efficiently parse the cvsps metadata files in .cvsps
> from scripts that will give the flexibility of parsing the data as
> you want or to quickly write a gui fronthand). This is low prio though,
> having -f working together with -r and all the other options is much
> more interesting at this point IMHO.  Being able to specify a directory
> as a file would also be very useful.

The file is actualy a substring match.  If the -f argument matches as a 
substring the filename it will count as a match.  So you can specify 
directory names just as is.

David

-- 
/==============================\
| David Mansfield              |
| david@cobite.com             |
\==============================/


[-- Attachment #2: Type: TEXT/PLAIN, Size: 1675 bytes --]

Index: cvsps.c
===================================================================
RCS file: /sulu/cvs_master/cvsps/cvsps.c,v
retrieving revision 4.70
diff -b -u -r4.70 cvsps.c
--- cvsps.c	19 Mar 2003 16:21:32 -0000	4.70
+++ cvsps.c	19 Mar 2003 21:11:15 -0000
@@ -1029,23 +1029,6 @@
     if (ps->psid < 0)
 	return;
 
-    if (restrict_date_start > 0 &&
-	(ps->date < restrict_date_start ||
-	 (restrict_date_end > 0 && ps->date > restrict_date_end)))
-	return;
-
-    if (restrict_author && strcmp(restrict_author, ps->author) != 0)
-	return;
-
-    if (have_restrict_log && regexec(&restrict_log, ps->descr, 0, NULL, 0) != 0)
-	return;
-
-    if (restrict_file && !patch_set_contains_member(ps, restrict_file))
-	return;
-
-    if (restrict_branch && !patch_set_affects_branch(ps, restrict_branch))
-	return;
-    
     /* the funk_factor overrides the restrict_tag_start and end */
     if (ps->funk_factor == FNK_SHOW_SOME || ps->funk_factor == FNK_SHOW_ALL)
 	goto ok;
@@ -1086,6 +1069,23 @@
     }
 
  ok:
+    if (restrict_date_start > 0 &&
+	(ps->date < restrict_date_start ||
+	 (restrict_date_end > 0 && ps->date > restrict_date_end)))
+	return;
+
+    if (restrict_author && strcmp(restrict_author, ps->author) != 0)
+	return;
+
+    if (have_restrict_log && regexec(&restrict_log, ps->descr, 0, NULL, 0) != 0)
+	return;
+
+    if (restrict_file && !patch_set_contains_member(ps, restrict_file))
+	return;
+
+    if (restrict_branch && !patch_set_affects_branch(ps, restrict_branch))
+	return;
+    
     if (!list_empty(&show_patch_set_ranges))
     {
 	struct list_head * next = show_patch_set_ranges.next;