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

[Bill Tutt <ra...@lyra.org>]

> 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