On 7/12/2011 12:25 PM, Mark Phippard wrote:
> On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton<andy_at_assembla.com> wrote:
>
>> Mark, I agree with you that the existing merge will work better if we apply
>> some restrictions. I can see that the project is already going that way,
>> and maybe it is good to continue in that direction. As a user, I would find
>> that helpful.
>>
>> However, we cannot get good results with the subtree merginfo format. It is
>> a failed architecture. A lot of smart people have worked on it, and they
>> have not achieved good results. It is the source of many annoying problems.
>> Even on this list, nobody defends it. They only express a desire for
>> "compatibility." You yourself have argued that basically, it can't be done,
>> that cyclic merge won't work. Yes, if you stick with the subtree merginfo,
>> IT CAN'T BE DONE. You are guaranteed to be right. However, if we free
>> ourselves from this one restriction, we can do something good. I invite
>> everyone to stop beating their heads against this wall.
>>
>> In my proposal, you can basically keep everything about Subversion the same:
>> the servers, most of the clients, the old merge command if you choose to use
>> it. It's all compatible. I am only asking you to give up ONE THING:
>> subtree merginfo. To succeed, we have to get rid of both parts of it. We
>> have to get rid of the subtree info, and we have to get rid of the fussy
>> little merginfo format. If newmerge is successful and we want people to
>> move to it, we can force the conversion by asking "svn" to read the old
>> merginfo and write some information into the new format.
> I really do not know if I agree with this, and I think you might be
> being a bit naive if you think that simply by creating a new format
> you are going to not have problems and you are going to even create an
> improvement. That said, I think some of the ideas around storing
> patches is at least interesting.
>
> I actually do not think mergeinfo is our problem or even our limiter.
> I agree it would have been easier to implement if we did not support
> all the odd cases we do, but at the same time, I think all of those
> odd cases are working pretty well now. So at best, removing support
> for that stuff might just make future work a bit easier.
>
> The problem in merge is in core SVN. Merge tracking was always based
> on the premise that merge in SVN worked fine, but it was annoying to
> have to manually track merges and specify the revisions to merge. So
> merge tracking tracks that and allows the simple merge syntax you are
> advocating. In that sense, merge tracking accomplished its goal and
> as of 1.7 the last of the warts in the implementation should be
> resolved.
>
> The problem is that SVN merge does not really work fine. The design
> of SVN makes cyclic merges really difficult and perhaps impossible.
> The lack of support for moves and renames makes merge not useful for
> people that refactor a lot etc. None of these are problems with merge
> tracking.
>
> You seem to want to extend merge tracking to provide new ways to solve
> these problems. Great, design it and propose it. I do not
> necessarily see why that info cannot be stores in properties, or even
> the existing property. Nor do I see why we cannot migrate the info we
> have to a new format. We need real design to have something to
> discuss.
>
> Finally, in your new design do not forget about things like log -g and
> blame -g, as well as the mergeinfo command. These features are all
> necessary parts of a merge tracking plan and must have answers from
> the first release.
>
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 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.
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.
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Received on 2011-07-12 18:41:07 CEST