> Keep in mind that some of the low level details of the fix you are
> making has caused me to not know what you are doing "conceptually". I
> was suggesting at the conceptual level, one way to solve the
> reflective merge problem is this.
>
> 1. User requests to merge a revision range (possibly all eligible revisions)
> 2. We gather all of the revisions to be merged
> 3. For each of these revisions, we identify which of those were
> themselves merges. (Look at whether mergeinfo was modified during
> that revision?)
> 4. For each revision that was a merge, we subtract out all of the ones
> that were a merge from their original copy source.
>
> An approach like this would work correctly for all of the use cases I
> presented. The trickiest one being the merge from one branch to
> another. In that example, we would filter out any revisions that were
> merges from trunk.
>
> I am just throwing this out there as a drive by. I have no idea if it is valid.
>
>
Similar Idea I had in mind, I did not take that path as it could lead to
potentially running through the full history of 'source' for 'target'
merges.
Thanks,
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 16:00:11 2007