Antwort: Re: Question about SVN::ReceiveLog

Stefan Küng <tortoisesvn@gmail.com> wrote:

> > * revisionStart >= revisionEnd
>
> In case that's not true, just swap the two.

Well my point is, that I always will report the revisions
in descending order (in constrast to the command line
interface). The problem is that forward-following the copy
"history" will create a tree of paths to follow.

> > * revisionStart may be HEAD, BASE or a specific
> > revision number
>
> In case of WC as the start revision, substitute it with BASE.

O.k. I will allow HEAD, BASE, WORKING, revNum for any of
the three revision parameters. This is not a problem as
long as there is only one path to handle.

> > * pegRevision defaults to revisionStart if
> > pegRevision < revisionStart or empty
>
> If revisionStart has to be bigger than revisionEnd, then we can't force
> the peg revision to be revisionStart. It should be possible to specify a

> peg revision to any possible revision (otherwise the whole peg thing is
> useless).

Again, the copy forward-following is the problem. Therefore,
"svn log path@1 -r4:3" may be ambiguous. What will actually
be returned is equivalent to "svn log path@4 -r4:3".

Of course, "svn log path@5 -r4:3" will follow all renames of
"path" until revision 4 is found.

> I haven't really looked at your code on the branch, but shouldn't it be
> possible to search the database for the url/path in the peg revision,
> then search up/downwards to the startRevision and adjust the paths
> accordingly?

You are right in that I have access to all information
required to traverse changes to and fro. In future, it may
be possible to follow all copy destinations at once (part
of that code is already available: the batch iterators).

-- Stefan^2.
Received on Wed May 2 23:53:08 2007