Re: Understanding Reflective/Cyclic Merges

On Nov 16, 2007 2:29 PM, Kamesh Jayachandran <kamesh@collab.net> wrote:

> >This seems like a hard problem, but I think if we are always filtering
> >out revisions that were the result of merges from the copy-source of
> >the target, then it is always the same algorithm and would work and
> >hold up. I am not sure if this is what Kamesh and Karl are doing or
> >not.
>
> I am not able to understand this.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org