On Sun, May 15, 2011 at 07:01:55PM +0200, Paolo Compieta wrote:
> (perhaps we should move to the dev-list? i'm not expert of this, i'll follow
> the thread)
Feel free to start a new thread on the dev list if you have a design
proposal or a patch.
> Said that rename=deletion++, i'd concentrate only on the following 2:
>
> 1.a) incoming delete vs local delete: i'd consider this a normal conflict:
> both trees could have moved that dir (that would look exactly the same
> before deletion): in this case, we should help to avoid duplicates.
>
> 1.b) incoming delete vs local edit: could we try something simplier
> than a tree-compare? I imagine (but i haven't studied apis, yet) that
> "checking for commits in a working copy tree" be cheaper than
> tree-comparing with the repository tree; 99% of times local commits
> actually mean the "local edit" we were searching, don't they? (I can
> only see a false positive if a file or a dir is first modified and then
> restored exactly equals in the wc branch)
>
> So we could check the following
> "has any local edit (commit) happened in the destination tree since
> last time they were OK?" (see below for "OK" definition)
> NO) ok to delete
> YES) tree conflict
>
> OK: branch copy/creation; or last successfull merge (i.e. a commit in the
> destination/wc tree) in which they had been successfully integrated,
> even if different/modified.
Interesting ideas. But I think that comparing trees will be much more
straightforward than this. You would have to use the log APIs and also
evaluate mergeinfo. And as you've noted this gives you no information about
how the changes local to the branch actually affect the local version of
the tree. Which is valuable information when making decisions about conflicts.
Received on 2011-05-16 12:24:17 CEST