Messages in this thread | | | Date | Wed, 19 Mar 2003 22:37:38 +0100 | From | Andrea Arcangeli <> | Subject | Re: [ANNOUNCE] cvsps support for parsing BK->CVS kernel tree logs |
| |
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/
| |