On Wednesday, June 12, 2002, at 12:24 PM, Ben Collins-Sussman wrote:
>
>
> A. 'svn cp' behavior
>
> Apparently libsvn_fs cheerfully allows destination overwrites when
> copying things. That is, if you use svn_fs_copy() to copy a file or
> directory, any entry which has the same name in the destination will
> be *removed*, and *overwritten* with the new item.
>
> According to cmpilato, this is an intentional fs design decision; I
> wasn't aware of it, but whatever. So be it.
>
> Because of this fs behavior, our client libraries do a number of
> "sanity checks" to prevent this behavior, when doing 'svn cp URL
> URL' in particular. The client libs will throw an error if the
> destination file already exists. However, the libs are *not*
> detecting the case when a destination directory already exists!
> Directories are just silently replaced.
>
> I don't like this at all. This is backwards from unix cp
> semantics. IIRC, unix cp allows you to overwrite files, but not
> dirs. Why are we doing it the other way around? I'm going to file
> an issue on this.
>
Actually unix "cp -r" of a directory does something similar to svn merge
(which I didn't fully appreciate until I just played with it). Without
the -r flag it just won't copy a directory at all. So I agree that the
current behavior seems either totally backwards or at least
inconsistent, depending on your point of view.
IMHO, 'svn cp URL URL' should either do a replace for both dirs and
files if the target exists, or it should fail for both, with my
preference for the replace (after all I'll just do the 'svn rm' first if
it doesn't behave that way). I suspect that failing for both is going
to be the preference of other people here, though, since otherwise the
URL->URL semantics might become inconsistent with the WC->WC semantics.
This problem goes beyond the dumper/loader issue, though. The bigger
problem for me is that the client doesn't deal well at all with the
current server side behavior. Replacing a whole dir via 'svn cp URL
URL' then doing an 'svn up' in another WC, just causes a client side
failure which then needs manual intervention to deal with. It seems to
me that legal operations on the server side should, as a rule, not cause
the client to automatically fail a legal client operation.
Usually what I do with the current 'svn cp URL URL' behavior, is, on the
client side, go and rename the dir that has been replaced to get it out
of the way, then 'svn cleanup; svn up'. lather/rinse/repeat for every
directory that may have been promoted. A nicer thing would be for the
client to detect the server side replace, automagically do the rename
for me (maybe to something.svn-backup for example), tell me it did that,
and successfully complete the 'svn up'. Again, I can see where others
might prefer something else.
The current behavior is a problem for my users though since they never
understand the client side failure message they see when this happens
(after every promotion I do) and I have to go and fix it for all of them
as well.. :^(
>
> B. Two kinds of 'replace'.
>
> Ronald Simmons thought that it was totally normal for 'svn cp URL
> URL' to overwrite destination directories. He was issuing this
> command over and over as a way of promoting code from one branch to
> another, rather than using 'svn merge' to port changes.
>
Don't know that I thought it was totally normal, but I kinda liked the
way it worked. :^)
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 12 22:57:51 2002