On 8/19/05, Dale Worley <dworley@pingtel.com> wrote:
> I would like to ask people to think about the interface issues here before
> rushing out the code.
> As I see it, the problem is that "svn copy" is ambiguous: If you do "svn
> copy .../aa/bb .../cc/dd", its operation depends on whether .../cc/dd
> already exists, or only ../cc. In the first case, it creates .../cc/dd/bb,
> in the second, it creates .../cc/dd. When the command is used
> "interactively", the user knows which case applies. But when the command is
> used in a script, it is much more likely that an error will happen, where
> the wrong situation obtains.
>
> IMHO, the correct solution is a version of "svn copy" that *requires* that
> .../cc/dd not exist, and reports an error if it does. (The reason for
> choosing that case is that the other case of "svn copy" can always be
> implemented in terms of this case, but not vice-versa.) Such a restricted
> version will not succeed but produce an unexpected result.
>
> Changing "svn copy" to "delete .../cc/dd if it exists, then replace it with
> a copy of X" is not, IMHO, a good idea, as it does a different version of
> the sort of conditional behavior that is causing the problem in the first
> case.
>
> If people feel a need to "delete X and replace it with a copy of Y", that
> should be performed as two steps. I do know that the WC can represent such
> a thing, as "svn merge" can get WCs into such a state. (It is flagged by
> "svn status" as "R".)
After problem investigation, I certanly agreed with You: subversion
should support delete and replace with copy instead of option to
command.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 16:25:50 2005