On 9/19/06, Daniel Rall <dlr@collab.net> wrote:
> The question: How should we record merge info when part of a merge
> into a WC is skipped?
>
> Garrett and I had a long discussion on IRC, where we boiled this down
> to two classes of use cases for "skipped notifications", which are
> hopefully helpful in addressing this problem:
>
> "Expected" skip:
> ================
> The skip notification results from a path which is "expected to be
> missing". Garrett thinks that we should record merge info for the WC
> target's entire tree.
FWIW, the justification for recording merge info here is that to not
record it doesn't actually help matters. When we say "expected to be
missing" that means the path in question was deleted and the delete
was committed. If we don't record mergeinfo then that path will
always show up as having that rev available for merge, and no matter
how many times you merge it in it'll never go away because the target
is never going to be there. If the target does come back (i.e. you
resurrected it via svn cp froma previous revision or something) then
the newly resurrected path will have the appropriate mergeinfo and the
revisions that were not merged into it (because it wasn't around) will
now show up as available to merge.
> "Unexpected" skip:
> ==================
> The skip notification results from a path which is "obstructed" or
> "missing, but expected to be there". I tend to think that we should
> record only partial merge info for the parents of these paths.
This seems reasonable because if you take care of the problem then you
might want to do the actual merge, so having the missing mergeinfo
lets our newer smarter merge impl do it for you.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 20 02:19:16 2006