Thank you for your answer. I missed that svn_ra_get_deleted_rev() is part of the server’s API. Thought it was client API.
Finally let me just describe two practical situations (in my case) where the lack of forward-history hurts: - You are unable to define svn:externals that stay always current, because you cannot define an external always pointing at “youngest revision on path@peg”, as long as you cannot be sure that those resource is never renamed /deleted - You are unable to let the user choose a younger replacement for an svn:external, because forward history is invisible. Btw, I don’t expect the log “to follow history forward (through all copies and moves and such)”. I do not think this birth defect of svn, namely that it cannot differ between moves and copies, can be reverted. I only expect log to show me at least the whole lifespan of an unique object (identified by path@peg). Greetings, Julian Von: C. Michael Pilato [mailto:cmpil...@collab.net] Gesendet: Montag, 5. März 2012 14:09 An: Ruhe Julian Cc: dev@subversion.apache.org Betreff: Re: AW: Suggestion for: "Improve svn log with 'forward' revision range" (Issue 3830) 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: What is the time complexity of the call svn_ra_get_deleted_rev()? 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:cmpil...@collab.net] Gesendet: Freitag, 2. März 2012 16:00 An: Ruhe Julian Cc: dev@subversion.apache.org<mailto:dev@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:cmpil...@collab.net] Gesendet: Freitag, 2. März 2012 15:32 An: Ruhe Julian Cc: dev@subversion.apache.org<mailto:dev@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@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@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@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@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@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@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 <cmpil...@collab.net><mailto:cmpil...@collab.net> CollabNet <> www.collab.net<http://www.collab.net> <> Distributed Development On Demand -- C. Michael Pilato <cmpil...@collab.net><mailto:cmpil...@collab.net> CollabNet <> www.collab.net<http://www.collab.net> <> Distributed Development On Demand -- C. Michael Pilato <cmpil...@collab.net><mailto:cmpil...@collab.net> CollabNet <> www.collab.net<http://www.collab.net> <> Distributed Development On Demand
