Re: [PATCH] make svnmucc consistently overwrite copy targets

Mark Phippard wrote:
> On Fri, Nov 7, 2008 at 8:54 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Philip Martin wrote:
>>> And Unix mkdir doesn't support it. The fact that svnmucc replaces
>>> directories when using mod_dav_svn might well be a server bug.
>> Philip, perhaps we should be tracking this situation as its own issue, and
>> pointing the dependent issues (I see you found another one) to it as, you
>> know, dependencies. Whaddaya think?
>
> There was a patch that came in last year that added a --replace option
> to the copy command. I personally think adding an option like that
> would be a good idea. I cannot comment on the fitness of the patch to
> be appled as was submitted. Here is the issue:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2727

Yeah, I'm talking more about the RA inconsistency we have today. My
findings four years ago point to a discrepancy with mod_dav_svn's handling
of copy operations, namely that it assumes folks want to overwrite a
pre-existing target (so it silently first deletes the things, then performs
the copy addition), whereas both ra_local and svnserve would flag an
obstruction in such a situation. The obstruction is the correct behavior
for our Subversion semantics, but today we have to work around mod_dav's
little feature by doing our own existence checks in advance of making copies
that might silently overwrite something in this one RA implementation. The
complication, unfortunately, is that as a generic DAV provider, mod_dav is
probably doing the right thing -- when you copy a file atop another in a
file explore, you expect a replacement to happen (perhaps with a prompt, but
still...). So we can just "fix" mod_dav.

Of course, we could just defer action here (as we have for four years
already) and just make the new HTTP protocol enhancements do what we want.
That way, Autoversioning still works as expected (where a copy atop an
existing thing is naturally expected to replace it), and our internal commit
drive semantics can also be preserved (because we are no longer using the
WebDAV COPY request for such things).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand