subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Shepelev <>
Subject Re: Automatically supply the origin URL in svn merge
Date Wed, 25 Mar 2020 22:10:25 GMT
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».


> 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

> 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
/\ [archived]

View raw message