Re: poor Brane

Branko �ibej wrote:

> Ben Collins-Sussman wrote:
>
>> It's gotta be a Windows-only bug. I tested all of the 'svn st -u'
>> functionality by deliberately working with a working copy that was ten
>> revisions behind the head.
>>
> What the ... "#=&"@! It *works* now!
>
> Ben, whatever you did in your latest commits, "svn st -u" now works
> for me on Windows -- *without* compiling the latest changes -- and I'm
> totally stumped.
>
> I really don't see how this is possible. I meant to try debugging the
> \ / issue, and now I can't. Don't know whether to be sad or happy
> about that.

Ah, it really isn't possible. I found the !#%@& bug.

libsvn_wc/adm_crawler.c:report_revisions() recursively crawls the
working copy. It keeps splicing the path and entry names together in
svn_path_local_style, as it must, if it wants to read entries and stuff

Then, if it finds an interesting file, it calls reporter->set_path
(libsvn_ra_dav/fetch.c:reporter_set_path()), which writes that path
straight into the REPORT body -- without changing it to URL style first.
Oops.

Now, the "obvious" solution is to convert the local paths to URLs in the
ra_dav reporter callbacks. But I have no opinion about whether it's the
correct solution.

I have a strong feeling there's a similar problem, but in reverse, in
ra_dav: If I check in two (or more) files that are not all in the
current directory, the checkin succeeds, but setting the WC props faile
-- this time, the anchor has \'s, but the target has /'s.

-- 
Brane �ibej   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org