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/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:28 EST