RE: svn commit: rev 2057 - branches/issue-654-dev/subversion/include branches/issue-654-dev/subversion/libsvn_fs branches/issue-654-dev/subversion/libsvn_repos

> From: cmpilato@tigris.org [mailto:cmpilato@tigris.org]
> + * Note Some More: Bill Tutt explains that a more generic way of
> + * knowing when to update the predecessor-id is when S and T are
> + * related, but as cousins in the ancestry tree. That is:
> + *
> + * ((S.NodeId == T.NodeId)
> + * && (! S == T)
> + * && (! S ancestorof T)
> + * && (! T ancestorof S))
> + *
> + * However, he has some uncertainty about how this holds up in the
> + * face of copies.

More specifically:
If the condition to perform a recursive merge is correct in the face of
copies then my suggestion is correct assuming that the thought process
is correct. Otherwise, we have a problem. :)

If the condition to perform a recursive merge changes, then so would the
filtering criteria to know when to update the predecessor-id.

FYI,
Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:11:03 2002