bryce.schober_at_gmail.com wrote on Tue, Aug 27, 2019 at 09:41:37 -0700:
> FWIW, I found the explanations in these two emails from the same thread to
> be easier to understand as a user:
> https://svn.haxx.se/users/archive-2010-11/0408.shtml
> https://svn.haxx.se/users/archive-2010-11/0466.shtml
>
> This sounds like yet another UX flaw caused by the constraints of
> subversion's characteristic "flexibility" afforded by its nearly-complete
> agnosticism regarding repository branching and tagging structure.
Quoting those emails (thanks for the links):
> [the change] allows for the following rules of thumb:
>
> - If you do a copy within a working copy of your branch, Subversion assumes
> that you want to copy something within your branch.
> - If you do a URL-URL copy, Subversion assumes that you want to create a
> new branch.
> The short story, the following behaviors are intentional:
>
> A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo
> if the source has it.
>
> B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit
> mergeinfo if the source has it. If the source doesn't have explicit
> mergeinfo, but inherits it, then that inherited mergeinfo is made
> explicit on the destination.
The surface problem here, as I see it, is this: the behaviour of 'svn cp
foo bar' depends not only on what PATH_at_REV coordinate each argument denotes.
I would have expected the following to be an invariant:
.
"«svn ${subcommand} ./foo_at_BASE» is equivalent to «svn ${subcommand}
$(svn info --show-item=url ./foo)@${svn info --show-item=revision foo}»."
.
or perhaps this:
.
"If «foo» and «bar» denote the same tree entry, then «svn
${subcommand} foo» and «svn ${subcommand} bar» are equivalent."
Either of these invariants implies that whether the arguments are
specified by URL or by local path should make no difference to the
result.
"In the face of ambiguity, refuse the temptation to guess."
Cheers,
Daniel
Received on 2019-08-27 23:01:45 CEST