subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Automatically supply the origin URL in svn merge
Date Wed, 25 Mar 2020 23:30:02 GMT
Anton Shepelev wrote on Thu, 26 Mar 2020 01:10 +0300:
> Daniel Shahaf:
> > 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?

Sure:

svn cp ^/trunk ^/branches/foo
svn cp ^/trunk ~/trunk2
[in a wc of branches/foo]
svn up
svn merge

Or

svn cp ^/trunk ^/branches/foo
svn mv ^/trunk ^/master
[in a wc of branches/foo]
svn up
svn merge

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

Neither am I.  I was just trying to describe the multiple different
uses of 'svn cp':

- create a branch

- rename branches

- rename files in a branch

- create a copy of a component, after which both sides of the copy
  continue independently (e.g., we might have run «svn cp 1.13.html
  1.14.html» to create the 1.14.x series' release notes)

- create a copy of a component, after which both the original and the
  new versions of the component continue hand in hand (e.g., we might
  have run «svn cp docs/ docs.ja/» to create a Japanese translation of
  the documentation, and thereafter used «svn merge» to move changes
  between the two directories)

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

Likewise.

By the way, it should be fairly easy to write a script that automates
this.  The main task is to find the copyfrom path, and that can be done
with a single command: `svn log -r 0:HEAD --stop-on-copy -q -v ./`.

Cheers,

Daniel

Mime
View raw message