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

Re: AW: Suggestion for: "Improve svn log with 'forward' revision range" (Issue 3830)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 5 Mar 2012 08:08:51 -0500

1) I'm pretty sure svn_ra_get_deleted_rev() uses a binary search method,
too, but has the luxury of doing so on the server side and without using the
costly 'log' operation.

2) Probably. My only concern is that we don't inadvertently take a UI step
that stands in opposition to a future step we may wish to take when we teach
'svn log' to follow history forward (through all copies and moves and
such). But truth be told, the value of this immediate improvement may just
outweigh any design discomfort we might experience in that (far?-)future
scenario.

On 03/05/2012 04:16 AM, Ruhe Julian wrote:
>
> Well, if this is the case, I have two questions:
>
> 1) What is the time complexity of the call svn_ra_get_deleted_rev()?
>
> 2) The solution of svn_ra_get_deleted_rev() is equivalent to the
> discussed problem. Couldn’t the “log”-issue immediately be solved then by
> using this call?
>
>
>
> Am sorry that I currently do not have the time to figure it out for my own
> (get sources, get used to C again). For me the issue is solved. But I
> would like to see an efficient solution in a next svn release. That’s why
> I am interested in this topic.
>
>
>
> Greetings,
>
> Julian
>
>
>
>
>
>
>
> *Von:*C. Michael Pilato [mailto:cmpilato_at_collab.net]
> *Gesendet:* Freitag, 2. März 2012 16:00
> *An:* Ruhe Julian
> *Cc:* dev_at_subversion.apache.org
> *Betreff:* Re: Suggestion for: "Improve svn log with 'forward' revision
> range" (Issue 3830)
>
>
>
> I'm pretty sure "valid" in this sense means "passes the
> SVN)_IS_VALID_REVNUM(rev) check", not "points to a known-good revision at
> which PATH existed".
>
> On 03/02/2012 09:55 AM, Ruhe Julian wrote:
>
> Hi Michael,
>
>
>
> I used client calls only because I am a user of svn not a dev. I did not
> want to modify any svn client code for my purposes. If you can access more
> suitable API calls for a solution of the problem the better. But I doubt
> from what I see in the signature of svn_ra_get_deleted_rev() that it is of
> much use. The method expects a valid end_revision and this is something
> you do not have initially. Imagine the object1 one existing in –r1:n and
> deleted in n+1 (HEAD) and object two existing in –r1:2 only with HEAD at
> n+1 as well. In both cases you need an educated guess for end_revision to
> get an useful answaer an not an exception.
>
>
>
> *Von:*C. Michael Pilato [mailto:cmpilato_at_collab.net]
> *Gesendet:* Freitag, 2. März 2012 15:32
> *An:* Ruhe Julian
> *Cc:* dev_at_subversion.apache.org <mailto:dev_at_subversion.apache.org>
> *Betreff:* Re: Suggestion for: "Improve svn log with 'forward' revision
> range" (Issue 3830)
>
>
>
> Doing this inside our client code would be significantly easier, because
> that code has access to the svn_ra_get_deleted_rev() API.
>
> /**
> * Given @a path at revision @a peg_revision, set @a *revision_deleted to the
> * revision @a path was first deleted, within the inclusive revision range
> * defined by @a peg_revision and @a end_revision. @a path is relative
> * to the URL in @a session.
> *
> * If @a path does not exist at @a peg_revision or was not deleted within
> * the specified range, then set @a *revision_deleted to @c SVN_INVALID_REVNUM.
> * If @a peg_revision or @a end_revision are invalid or if @a peg_revision is
> * greater than @a end_revision, then return @c SVN_ERR_CLIENT_BAD_REVISION.
> *
> * Use @a pool for all allocations.
> *
> * @since New in 1.6.
> */
> svn_error_t *
> svn_ra_get_deleted_rev(svn_ra_session_t *session,
> const char *path,
> svn_revnum_t peg_revision,
> svn_revnum_t end_revision,
> svn_revnum_t *revision_deleted,
> apr_pool_t *pool);
>
>
>
> On 03/02/2012 09:04 AM, Ruhe Julian wrote:
>
> Hi,
>
>
>
> Stefan Sperling asked me to post some details in respect of a suggestion I
> wanted to make for issue 3830
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3830
>
>
>
> It took me some time to understand that it is _/not/_ possible for the svn
> client to display the future of an object in some revision when it no
> longer resists on the initial path or was replaced by another object on
> the same path.
>
> Well, here is the pseudo code of my algorithm to determine the forward
> history & backward history of a svn path_at_peg in logarithmic time (it
> should terminate quickly in most real world situations):
>
>
>
> log[] getFullRemoteLog(urlOfObject, revOfObject)
>
> url = urlOfObject
>
> peg = revOfObject
>
> // start to fetch complete forward & backward log of url_at_peg
>
> endRev = repsitory.getLastChangedRevision()
>
> try
>
> // first try the regular way
>
>
>
> // using HEAD instead of HEAD’s rev number
> as endRev produces wrong results in svn 1.6.
>
> // see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3931
>
> return svn log url_at_peg -r endRev:1
>
> catch exception
>
> // OK, no problem. Remote file does no
> longer exist on HEAD. Proceed.
>
>
>
> startRev = peg
>
> youngestRev = determineYoungestRevision(url,
> startRev.number(), endRev.number(), false)
>
> return svn log url_at_peg -r youngestRev:1
>
>
>
> rev determineYoungestRevision(url, startRev, endRev, objectFound)
>
> if startRev == endRev
>
> return startRev
>
>
>
> testRev = startRev + (endRev - startRev) / 2
>
> if objectFound
>
> try
>
> svn info url_at_testRev -r
> startRev
>
> // test revision exists =>
> proceed forward in history
>
>
> determineYoungestRevision(url, testRev, endRev, true)
>
> catch exception
>
> // test revision does not
> exist => go backward in history
>
>
> determineYoungestRevision(url, startRev, testRev - 1 , true)
>
>
>
> // right object not yet found
>
> try
>
> log[] = svn log url_at_testRev -r testRev:1
>
> // object hit! But is it the right one?
>
> for i:log.length // no need to improve as
> svn requests dominate Running time
>
> if log[i -
> 1].getRevision() >= startRev && log[i].getRevision() <= startRev
>
> // right
> object found! Now find youngest object revision.
>
> return
> determineYoungestRevision(url, log[0].getRevision(), endRev, true)
>
> // not the right object!
>
> return determineYoungestRevision(url,
> startRev, log[log.length - 1].getRevision() - 2, false)
>
> catch exception
>
> // no object hit!
>
> return determineLastYoungestRevision(url,
> startRev, testRev.getNumber() - 1, false)
>
>
>
> Greetings,
> Julian
>
> p.s. please cc me. I am not subscribed
>
>
>
>
>
> --
> C. Michael Pilato <cmpilato_at_collab.net> <mailto:cmpilato_at_collab.net>
> CollabNet <> www.collab.net <http://www.collab.net> <> Distributed Development On Demand
>
>
>
>
> --
> C. Michael Pilato <cmpilato_at_collab.net> <mailto:cmpilato_at_collab.net>
> CollabNet <> www.collab.net <http://www.collab.net> <> Distributed Development On Demand

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2012-03-05 14:09:43 CET

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

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