Re: E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

[Vincent Lefevre]

On 2014-02-14 18:34:52 +, Philip Martin wrote:
> Vincent Lefevre  writes:
> 
> > With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error
> >
> > svn: E175013: Access to '/svn/' forbidden
> >
> > when I do "svn diff -r118:119 https://host//subdir";, but
> > "svn diff -r118:119 https://host//subdir/file"; is OK.
> >
> > There's no such problem with svn 1.6.12 (r955767) on some other
> > Debian machine and svn 1.7.9 (r1462340) on an Ubuntu machine.
> >
> > I can't find bugs with E175013 on the issue tracker.
> >
> > Note: I am not the admin of the svn server, so that I don't have
> > information about it.
> 
> Just to be clear, you mean that 
> 
>svn diff -r118:119 https://host//subdir
> 
> returns a diff with 1.6.12 and 1.7.9 but with 1.8.5 it fails with
> E175013?

Yes, that's what I meant.

> A network trace would help, but I've never had much success getting
> wireshark to decode an https conection even when I have access to the
> server.  It might be easier to use a debug version of the client to
> determine which request is failing.

Couldn't svn write it in the error message?

> You may be able to determine which version of Subversion is in use on
> the server by examining the HTTP headers with something like "curl -D-".

It doesn't say which version. Even for the WWW server, it just says:

Server: Apache

But if this is useful, I suppose I could get information from the
admin.

> What sort of change is r119?  Text/properties/adds/deletes/copies?

Just text change. And it is not specific to r119. All diffs between
two *repository* revisions seem to fail.

In a working copy, "svn diff -r118:119" fails, but not "svn diff -r118".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

svn_ra_get_file_revs2 vs. blame vs. FS API

[Stefan Fuhrmann]

Hi there,

r1568600 uncovered an inconsistency in our API usage / interpretation
making blame -g tests fail for FSX.

The starting point is svn_fs_contents_changed and svn_fs_props_changed.
FSFS and probably BDB implement those as "has there been an intermittent
change?" E.g. if the result of some merge yields equal content on both
sides,
they will still be considered "changed". That is a violation of the API
definition
basically asking "is the delta empty?". Even the FSX code is not fully
consistent
with that, yet.

svn_ra_get_file_revs2 uses svn_fs_contents_changed to decide whether
a delta should be sent to the given handler. The false positives returned by
FSFS and BDB are benign since we simply end up sending an empty delta
(a mere waste of CPU cycles).

However, our blame implementation relies on those false positives because
it tracks contents from revisions to be merged later separately from
"mainline"
changes. When the merge finally happens but results in the same contents
as the previous branch revision, the delta handler must be called to pull in
the blame info from the branch. The latter no longer happens with the strict
interpretation of svn_fs_contents_changed.

I see the following options:

* Redefine svn_fs_contents_changed and svn_fs_props_changed to match
  the current implementation. I'd rather not but that just a -0 from my
side.

* Make svn_ra_get_file_revs2 always accept a delta handler unless the
  previous change was on the same branch and the delta is empty (e.g.
  just a prop change). Sounds arbitrary, so -0 on that too.
* Make svn_ra_get_file_revs2 accept delta handlers (roughly) as today
  but use the log information for that, i.e. whenever the content modified
  flag is set for the respective file path. That would be sound approach
  since we are in rev_hunt.c anyway. The info may already be available
  (haven't checked yet).

* Make the blame implementation update the mainline blame info even
  if no new delta info came in but the previous callback wasn't for the
  mainline.

I suggest to do any of the last two or even both.

-- Stefan^2.