Daniel Shahaf:
> Stefan Sperling wrote on Wed, 25 Mar 2020 15:07 +0100:
> > On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote:
> > > 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
Stefan, is it by mistake that you omitted `branches':
svn copy ^/branches/mybranch/dir1 ^/branches/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».
Yes.
> 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 my proposal, SVN should search the histrory of the SVN path
corresponding to the current working directory for the most recent
`svn cp' command with that directory as destination, and use the
source of that command as the URL from which to merge.
> 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.
Futhermore, this is the most basic and most frequent merge
scenario, the other ones being *much* rarer. I propose to automate
the most frequent use case, for that is the ergonomically right
thing to do: make the most frequently needed actions the easiest.
> 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.
You say the project was renamed, which means that `svn cp' was not
involved. Accoring to the description above, my proposal is simply
not applicable in this situation. `svn merge' should terminate with
the error: "Merge source cannot be automatically determined.
Please, specify it on the command line."
> 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 fear I do not understand this case. Can you please post a
sequence of svn commands that reproduce it, even as Stefan did
above?
> I agree the tool could be smarter if it had notions of "branch
> root" and distinctions between "branching", "forking", "copying",
> and "renaming";
Like Git? But that would mean more complicated also, and I like
SVN for the simplicity of its data model: the evolution of a
directory tree, and do not propose to change the fundamentals.
> 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.
Certainly not. I still hope that my proposal can be made safe.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
