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

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Mar 19, 2003 at 04:19:20PM -0500, David Mansfield wrote:
> > 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'm downloading the new version now... ;) thanks

> > 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.

ok, it sounds very reliable even w/o atomic commits.

> 
> > 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'

Ok good, I'll check it.

> 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).

Is the -f a regex too? I mean, can I use '|^$'?

> 
> > 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 

so it doesn't sound a regex. Being able to specify more than 1 -f would
be very useful. Either that or regex would do it fine too with
'^net/core', so as far as I can write stuff like -f
'^net/core|^net/ipv4' I'm fine.

I also think using match by default in the regex is cleaner. So I can
write -f 'net/core|net/ipv4' w/o bothering about the ^ because it become
implicit. And I can still use '.*net/core.*' if I want a substring
regex. I think substring search will be not common.

But really, any kind of way you implement the 'multiple file' thing is
fine as far as I can specify more than 1 file ;).

thanks.

Andrea