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@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
