[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: It's time to fix Subversion Merge

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 12 Jul 2011 12:46:07 -0400

On Tue, Jul 12, 2011 at 12:40 PM, Andy Singleton <andy_at_assembla.com> wrote:

> Good point.  If we allow foreign merges, then "log" and "blame" are not
> going to work well.  They will show changes coming from the merge, rather
> than from the original commit.  Fine.  I'm willing to give up those details,
> because merge is important.  People will be happy with that if they give up
> some detail and get a merge that works.  If you want log and blame details,
> then don't do foreign merges.

I was not even speaking about foreign merges. I would be fine with
supporting those but not with log/blame. I am just saying if you
invent a new merge tracking format that you have to support it in
log/blame/mergeinfo too.

> I have made a specific proposal for handling moves and renames that is not
> very complicated.  Moves and renames can be identified by file name pattern
> matching.  This is the tactic that is used by git and subversion trumerge,
> so we know it works well in practice.  Once moves are spotted by the merge,
> we can write the changes back in our merge commit, using the existing
> copy+delete mechanism for writing moves.  And, we can record the move in our
> merge_history file so that changes can be mapped automatically in future
> merges between between branches that don't have the move, and branches that
> do have the move.

Hmm, I guess I did not see your proposal as being specific. For
example, trumerge works by doing some fairly extensive examinations of
the entire repository history to build a cache of moves. It then
constructs a merge script that it runs that does many merges to
implement it. I am still not convinced this is easy. That said, IMO,
this is the most important feature we need. So I am totally willing
to give you some runway to go solve it.

> This proposal is straightforward, but is not compatible with subtree
> merginfo.  It's pretty easy to do this mapping on one branch.  It starts to
> get complex and slow and problematic if you have to do it recursively on
> subtrees.  And, we can't record the mapping in the existing merginfo format.

I get that you do not want to support subtree mergeinfo. I am simply
saying why can't we invent a mechanism for a project to indicate that
it does not want to allow subtree merges so that they can enjoy these
new merge features? I think you have to invent this even if you
create a new command, and I am just saying that once you invent this,
you do not need a new command.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-12 18:46:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.