Stefan Sperling wrote on Wed, 25 Mar 2020 15:07 +0100:
> On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote:
> > Hello, all
> >
> > Why does even the basic sync-merging require that the user
> > specify the source URL, as in:
> >
> > svn merge ^/project/trunk
> >
> > I think this requirement is redundant because SVN know
> > exactly from which original original directory the branch
> > was created by svn cp. Will you consider simplifying the
> > basic merge syntax to:
> >
> > svn merge
> > svn merge <local_path>
> >
> > so that SVN shall supply the origin URL automatically? Or
> > am I wrong, and my proposal makes no sense?
>
> Recall that SVN cannot know whether a copy operation is supposed to
> create a new branch, or to copy a folder within the scope of a branch.
> This distinction exists only in the human mind, not in the tool itself.
>
> Also recall that users have the ability to check out a working copy
> from any level of the tree.
>
> When we combine your idea with the above two aspects of SVN's design,
> we run into a problem.
>
> Example:
>
> svn mkdir ^/trunk
> svn mkdir ^/trunk/dir1
> svn copy ^/trunk ^/branches/mybranch
> svn copy ^/mybranch/dir1 ^/mybranch/dir2
> svn checkout ^/mybranch/dir2 my-dir2-working-copy
> cd my-dir2-working-copy
> svn merge
>
> What will happen now?
Same thing as if the user had run «svn merge ^/mybranch/dir1».
In general, I understand the proposal as saying that «svn merge» without
arguments would default to looking up the most recent copy of cwd, and
merging into cwd the URL cwd had been copied from.
In your example, I think that would be a reasonable thing to do: for
all we know, the component had been forked (à la libsvn_fs_fs to
libsvn_fs_x, stsp) and the described merge is in fact what the user
wants to do. However, I can also see circumstances in which this
smartness could be counter-productive:
1. In repository restructurings, such as running «svn merge» in a
working copy of ^/thebarproject/trunk after that project had been
renamed from ^/thefooproject/trunk. Under the proposal, that would
attempt to merge from ^/thefooproject/trunk, and it's not clear to me
that that's a more useful behaviour than just throwing a usage error.
2. We can't trace copies forward. If trunk had been renamed or forked
after the merge, a simplistic "Take the copyfrom_path_at_copyfrom_rev,
change the copyfrom_rev to 'HEAD', and use that as the URL to merge
from" wouldn't necessarily be correct.
I agree the tool could be smarter if it had notions of "branch root"
and distinctions between "branching", "forking", "copying", and
"renaming"; however, I don't think the lack of these distinctions is
necessarily a blocker. It just means we need to be more careful about
not writing automation that will help some cases and backfire in others.
Cheers,
Daniel
Received on 2020-03-25 22:02:45 CET