Date: Wed, 19 Mar 2003 22:37:38 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: David Mansfield <david@cobite.com>
Cc: David Mansfield <lkml@dm.cobite.com>, linux-kernel@vger.kernel.org,
       Larry McVoy <lm@bitmover.com>
Subject: Re: [ANNOUNCE] cvsps support for parsing BK->CVS kernel tree logs
Message-ID: <20030319213738.GR30541@dualathlon.random>
References: <20030319201101.GQ30541@dualathlon.random> <Pine.LNX.4.44.0303191600150.19298-200000@admin>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0303191600150.19298-200000@admin>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4211
Lines: 95

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/