Re: Issue 2897 revisited. Really.
>> I think issue #2897 is really two separate issues rolled into one.
>> Disentangled, they are:
>> 1) When you merge a BRANCH to TRUNK, don't merge back revisions
>> which had previously been ported from TRUNK to BRANCH.
>> 2) Don't lose conflict resolution work (where "lose" can mean
>> "mistakenly lump it in with purely merged changes").
> Yes I am working on , the Idea I have to solve that bit is,
> *Don't filter the reflective merge commit rev, rather merge it
> differently by having separate editor hooks defined in the client/wc level.
> Let us say
> - someone 'merge -r50:150 from /feature branch' to trunk working copy.
> - He already synchronized trunk to /feature branch and committed at r96
> In issue-2897 branch code does 'merge -r50:95 from /feature branch' and
> 'merge -r96:150 from /feature branch', This looses changes from
> - local edits to resolve conflicts etc.
> - merge from some other source part of the same commit.
> My thoughts on solving this further may be on issue-2897 branch or part
> of some new issue branch.
> - Introduce the new boolean member 'is_reflective' to 'svn_merge_range_t'.
> - While populating 'remaining_ranges' populate this field when we
> encounter a reflective revision
> - non_reflective_merge_editor which would analyze the given revision
> number and do relevant non-reflective portions(adhoc local mods/merge
> from some other source part of this commit)
> - 'merge -r50:95 from /feature branch'
> - Oh r96 is a reflective, Use non_reflective_merge_editor to merge the
> non-reflective changes.
> - 'merge -r96:150 from /feature branch'
This is a very special case of effectively doing a subtract during merge,
but it won't solve the general case (e.g. when having multiple branches
you are also merging in-between).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 30 13:12:08 2007
This is an archived mail posted to the Subversion Dev