Yes, I agree. If merge handles moves, and if merging between branch
and trunk doesn't require arguments and reintegrate, then it would work
in enough cases to make people comfortable with the review-and-merge
workflow.
It does seem that moves and renames cause a high percentage of user
complaints. People don't commit moves in the correct way, and they
never will, and they get merge problems even if they do. It is possible
that you could eliminate about 90% of these complaints by
* Putting in an agent that looks for moves and renames heuristically,
assumes that it is correct when it finds something, uses the information
for any current merge or update.
* Add move information to next commit, to make it easier to handle moves
and history in the future. This step is apparently optional, as git
handles moves more effectively than subversion using only the heuristic
detection, without move tracking.
On 4/19/2012 9:26 AM, Mark Phippard wrote:
> I have no objection to coming up with some hook scripts to help
> enforce merge policies. I recall seeing this project on users@:
>
> http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Main_Page
>
> It adds the ability to block subtree merges by rejecting commits that
> add mergeinfo below the root.
>
> My concern is any link between these scripts and our merge code. It
> sounds like the plan would be to create these policies and then come
> up with a newmerge command that does not support any of the features
> these policies block? You obviously have no way to know that the hook
> scripts have been installed, so I would guess at a minimum your new
> command would have to detect all these problems and error out rather
> than run and produce invalid results.
>
> I honestly do not think these sorts of issues are what most of our
> users are struggling with. You can do whole branch merges today, you
> can block subtree merges with scripts if that is important etc. Most
> users seem to learn and adjust to --reintegrate. It seems like Julian
> has figured out a way to get rid of the --reintegrate option and if he
> is able to do it while still knowing when to do all the reintegrate
> checks, then subtree merges are no longer an immediate problem.
> Julian also seems to have some nice ideas on improving the output from
> the commands to make the process more understandable.
>
> Where I see users struggling with merges is when it comes to tree
> conflicts. People rename stuff frequently and then merge in SVN
> becomes nearly unusable. If we want to really fix merge, I think we
> have to improve how renames are handled.
>
> Andy expressed a desire to provide a code review workflow. With the
> right UI to make the branch creation easy (as well as of course the
> review), I think you could to that today. There is no reason that
> issues like subtree merges and criss-cross merges etc. should make it
> difficult to provide a feature like that because the UI would steer
> the user away from doing that. The blocker that does exist today is
> that we do not handle things like renames well.
>
> Back to your proposal, if users could easily put hooks in place to
> block certain merge features it would make our existing merge easier
> as well. I guess I am just saying it does not get us off the hook for
> needing to support those features in our merge for the people that do
> want to use them.
>
> Mark
>
>
>
> On Thu, Apr 19, 2012 at 6:48 AM, Stefan Fuhrmann
> <stefanfuhrmann_at_alice-dsl.de> wrote:
>> Hi all,
>>
>> After having a closer look at merge and discussing it
>> with Julian on IRC, there seems to be no silver bullet.
>> However, we identified a few things that could be changed
>> and set of constellations that make merge harder than
>> it needs to be.
>>
>> For the first, there will be another post soon. The second
>> boils down to policy. Luckily, SVN has a mechanism to
>> enforce policies: server-side hook scripts. My proposal
>> is to develop a small set of scripts that a user can
>> combine to prevent situations that her life harder than
>> necessary. This should give us enough time to improve
>> the merge logic inside the SVN libs.
>>
>> The following pre-commit scripts / policies would be useful.
>>
>> * Common parts [not a policy]
>> We first check whether the commit contains a changed
>> svn:merge-info property. This limits the performance
>> impact on non-merge commits and we need to identify
>> all changed svn:merge-info anyway.
>>
>> Also, the merges that happened on the source branch
>> from a different location than the target branch are
>> of no interest for the policy checkers. E.g.:
>>
>> r20: merge r19 from ^/sub-branch to ^/branch
>> txn: merge r10-20 from ^/branch to ^/trunk
>> Both merges will show up in the merge-info delta but
>> we only need to evaluate the second one.
>>
>> * Strict merge hierarchy
>> A merge from A->B is only allowed, if the copy-from
>> of A is B or vice versa and the copy source has not
>> been replaced since the copy). This prevents circular
>> merges and others (note 1).
>>
>> In a more sophisticated implementation, we could identify /
>> allow for renamed branches as well as A and B having
>> the same relative path to some parents that form a
>> direct branch (i.e. allow sub-tree merges).
>>
>> * No sub-tree merges
>> Like the above but without the check for parents.
>>
>> * No aggregate merges
>> There must only be one source branch, i.e. we can't
>> merge from branches A and B to C in the same revision.
>>
>> * No distributive merges
>> For each path being merged (i.e. having a merge-info
>> delta), the relative paths in source and target must
>> correspond (i.e. start as the same and then may get
>> renamed etc.). This is basically the same as the
>> "sophisticated" part of the check for strict merges.
>>
>> * No cherry picking
>> Check that the source branch does not contain revisions
>> that lie before the last to-be-merged revision but
>> have neither been merged before nor are being merged
>> right now.
>>
>> * No criss-crossing
>> Prevent situations like the criss-cross examples here:
>> http://wiki.apache.org/subversion/SymmetricMerge
>>
>> For a merge A->B, abort if there has been a merge
>> B->A after the last revision of A to be merged to B.
>> This only valid for non-cherry-picking merges and
>> only if the change sets of both merges overlap.
>>
>> Except for the last one those checks will simply verify
>> that the user followed certain policies. They should,
>> therefore, rarely reject a commit.
>>
>> Again, the user shall be free to combine (or not use)
>> these policies although not all combinations are meaningful.
>>
>> Thoughts?
>>
>> -- Stefan^2.
>>
>>
>> Note 1:
>>
>> One thing that we might want to support is integration
>> branches where a temporary branch is being used as
>> an intermediate merge target:
>>
>> integrate A->B as
>> rN: copy B->A_integration
>> rN+1: merge A->A_integration
>> rN+x: ... various changes on A_integration
>> rN+y: merge A_integration->B
>> rN+y+1: delete A_integration
>>
>> These checks become more complicated, requires
>> naming conventions for the integration branches etc.
>
>
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Received on 2012-04-19 15:52:35 CEST