[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Antwort: Re: Question about SVN::ReceiveLog

From: <Stefan.Fuhrmann_at_etas.de>
Date: 2007-05-02 23:52:51 CEST

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

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.