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

Re: Cannot get info for a file that was inside of file-replaced directory

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Sun, 24 Nov 2019 16:01:24 -0500

On Fri, Nov 22, 2019 at 2:00 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Let's continue the discussion on dev@. [Moved from users@]

I didn't (much) get into the code yet except for a quick skim through
svn_client_info4().

If my understanding is correct, the change in r1823327 has to do
solely with reporting about locks.

Prior to r1823327, 'svn info' on an old revision could spend
significant time to determine if an object in question is the same as
an object in HEAD, in which case it would check if a lock applies to
the object.

The performance was sped up considerably by changing the search
direction for the "same object" check. But as Ivan points out, under
whatever set of circumstances (such as those exposed by Ivan's repro
script), a replaced object is no longer found by 'svn info' with a peg
revision:

$ svn info "$repo/dir/file"@1
svn: E160016: Failure opening '/dir' in revision 2
svn: E160016: '/dir' is not a directory in filesystem '(snip)'

My initial thoughts (I have NOT yet tested any of these):

(1) This line in svn_client_info4():

  SVN_ERR(same_resource_in_head(&related, pathrev->url, pathrev->rev,
                                ra_session, ctx, pool));

    would terminate if any error occurs in same_resource_in_head().
    Perhaps we should: check the specific error code; consider certain
    error codes as signifying that the object is not locked, set
    lock = NULL, and proceed?

(2) Alternately, perhaps svn_client_info4() should remain as-is and
    instead same_resource_in_head() should change: Maybe under certain
    conditions that currently return an error, it should instead
    set *same_p = FALSE and return SVN_NO_ERROR?

(3) If all else fails, an admittedly naive and kludgy fix might be to
    try the "new fast" search first; if it fails, fall back on the
    "old slow" search? Generally I *really* don't like to introduce a
    kludge unless as a last resort so hopefully there is a better way.

(4) Optimization: Currently same_resource_in_head() is being called
    unconditionally. Perhaps this should not be called at all if there
    are no locks?

> P.S. Nathan, are you aware of this syntax? — «svn log --diff -x-wp -c r1823327»

I actually never noticed that 'svn log' has a --diff option!! Thanks
for mentioning that!

Nathan
Received on 2019-11-24 22:01:46 CET

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