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
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.
const char *path,
On 03/02/2012 09:04 AM, Ruhe Julian wrote:
Stefan Sperling asked me to post some details in respect of a suggestion I wanted to make for issue 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()
// 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
// 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
testRev = startRev + (endRev - startRev) / 2
svn info url_at_testRev -r startRev
// test revision exists => proceed forward in history
determineYoungestRevision(url, testRev, endRev, true)
// test revision does not exist => go backward in history
determineYoungestRevision(url, startRev, testRev - 1 , true)
// right object not yet found
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.getRevision(), endRev, true)
// not the right object!
return determineYoungestRevision(url, startRev, log[log.length - 1].getRevision() - 2, false)
// no object hit!
return determineLastYoungestRevision(url, startRev, testRev.getNumber() - 1, false)
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
Received on 2012-03-02 15:56:15 CET