On Fri, Jul 3, 2026 at 10:50 AM Jordan Peck <[email protected]> wrote:
> > I don't have the setup to verify this situation today, but I
> > suspect that Jordan does.  What happens when you repository URIs
> > differ and a, say, a text file that contains the URL of the master
> > repository is committed?  Does that file's content on the slave
> > mirror repository still carry the URL of the master repository, or
> > has it been tweaked to look like a mixture of master hostname and
> > slave path?
>
> In my latest commit on the branch I added a test for this based on the
> issue you linked and it does indeed fail, although not silently. In
> the test case the URLs "master" and "slave" have different lengths,
> which causes the commit to abort due to "E185004: Unexpected end of
> svndiff input". I also tested with "master" and "slavex" which instead
> triggers a "E200014: Checksum mismatch", so I don't think any silent
> corruption is occurring.

Thanks for verifying this.  Issue #3445 also mentions changes unwanted
changes to properties (see
https://issues.apache.org/jira/browse/SVN-3445?focusedCommentId=14928251&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14928251
).
I wonder if those would enjoy the same protections via checksums that
exist for file content?

> My fix to the move/copy proxy shouldn't be affected by this at all, as
> it's only rewriting the destination header which will never contain
> file data.

Correct.  And sorry if I seemed to imply a problem with your patch.  I
think the patch is fine.  Where I was hung up was that I read the
patch as offering a bugfix for a situation that arises from having
mismatched master and slave URIs, but it seems that _even with the
patch_ we should not be recommending that folks setup their WebDAV
proxies in that manner (unless they have other ways to mitigate the
aforementioned risks).

Of course, it's possible also that I misunderstood the full scope of
what your patch fixes.  It's been a long time since I read Subversion
code!

-- Mike

Reply via email to