Hi Kamesh,
kameshj@tigris.org wrote:
> Author: kameshj
> Date: Sun Aug 19 10:30:16 2007
> New Revision: 26176
>
> Log:
> Fix issue 2754 - "Can't merge to target with Added children with mergeinfo".
>
> We fix this by checking the direct-copy relationship between
> subtree merge target and the corresponding source and viceversa.
> If they are related we continue with 'implicit subtree merge' on a
> guessed merge source url, else we set the children_sw_or_with_mergeinfo's
> corresponding slot to 'NULL' and contiune with next subtree.
>
I wonder if this check is correct for certain edge cases. For example,
if we have /branches/foo which was copied from /branches/bar which was
itself copied from /trunk, then a merge from /trunk into a /branches/foo
WC which has children with explicit mergeinfo would fail your check,
because the children of /branches/foo were not copied directly from
/trunk. As a result, those children would be merged as part of the
top-level do_merge() and potentially cause conflicts.
I think this issue could be fixed in a different way. IIUC, the problem
is caused by children of the merge target that have explicit mergeinfo
but whose corresponding merge sources do not exist in the repository.
The question is, why does get_sw_mergeinfo_paths() select all children
with explicit mergeinfo and not just those that have explicit mergeinfo
*for the merge source*?
If a child doesn't have mergeinfo for the merge source then that
mergeinfo does not affect the revision ranges that need to be merged and
therefore we don't need to merge it separately. If we don't merge it
separately, then the fact that the merge source doesn't exist doesn't
matter any more. OTOH, if a child does have mergeinfo for the merge
source, this tells us that the merge source actually exists.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 19 21:46:21 2007