(perhaps we should move to the dev-list? i'm not expert of this, i'll follow
the thread)
I've removed code references cause i'm asking a few more "conceptual"
questions here, to understand if we can simplify the detection avoiding the
diff. Fire me if i become trivial.
On Wed, May 4, 2011 at 12:03 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>
>
> To determine whether the deletion of a directory causes a tree conflict,
> we need to know whether the directory that has been deleted in the merge
> source had the same content as the corresponding deleted directory in
> the merge target. If it did, there is no conflict so it can be safely
> deleted. If it did not, a tree conflict needs to be flagged.
>
> The problems we were facing are as follows:
>
> 1) At present, it is impossible to tell apart a rename from a deletion.
You seem to be concerned mostly about reliably detecting the following
> situations:
> incoming delete vs. local edit
> incoming delete vs. local rename
> incoming rename vs. local rename
> incoming rename vs. local delete
> It helps to keep in mind that all of the following cases look the same
> to Subversion at the moment:
> incoming delete vs. local rename
> incoming rename vs. local delete
> incoming rename vs. local rename
> incoming delete vs. local delete
> The last case is not really a conflict but needs to be flagged as such
> because it looks the same as the former three possibilities.
> So you would still have to check each reported tree conflict for validity.
> This behaviour already applies for files in 1.6.x though, so it's a
> problem that isn't unique to directories. It is nevertheless annoying.
> But maybe less annoying than the current situation.
>
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.
next days i'll start to have a look at the code; if there are no
good/feasible
ideas above, i also think tree compare is the clean solution.
2) Comparing a mixed-revision working copy to a tree in the repository
> (which is always at a single revision) can produce spurious differences.
> However, as of 1.7, merges into mixed-revision working copies are
> disallowed
> by default. So this problem is now less of a concern than it used to be.
>
ok to leave this out from the rest of the thread
3) Comparing a local tree to some tree in the repository usually implies
> quite a bit of network and server-side processing overhead. It will be
> quite noticeable in most environments. This comparison would need to be
> performed for every incoming deletion of a directory. It's already being
> done
> for files but comparing entire directory trees will in general take longer.
> Having some kind of optimisation in place for this purpose would be good.
> However, I'd favour correctness over performance.
>
> 4) We need the above comparison to be reliable. I don't remember the
> details, but I think we found problems with the diff implementation
> while trying to compare a working copy tree to a repository tree.
> These problems may have been due to corner-case bugs since this kind
> of operation is rarely tested in practice. But it might also have been
> due to the mixed-revision working copy problem, which we can now ignore.
> There is some research left to be done here.
>
I'm for reliability, too. I'd only (eventually) welcome some false positives
in favour of big optimization (waiting for the real rework in 1.8).
Received on 2011-05-15 19:02:26 CEST