[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge_tests 27 obsolete?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 03 Dec 2008 12:05:40 +0000

On Fri, 2008-11-28 at 00:27 +0100, Neels J Hofmeyr wrote:
> Hi all,
> we're fixing the way tree-conflicts treat obstructions, which causes
> merge_tests.py 27 to fail (among others).
> But I find that this test wants lenient behaviour that shouldn't be allowed:
> A directory exists locally and is unversioned.
> Merge adds a directory of the same name.
> This is currently allowed. See also issue #2222, there is a fix for this
> explicit situation in r13358.
> But I don't get it. If the directory is obstructed, it's obstructed! Why
> should this be an exception? Shouldn't it then first take a look whether
> that directory is empty or something? I'd say get rid of this.
> If an unversioned directory obstructs a merge, svn should say so and skip
> it, as with any other obstructions. Finish en klaar.

In summary: I adjusted the code to make this exception so that test 27

A comment in the code, and Greg, both said something along the lines of:
"We allow this case because we can do so without destroying the user's

1. The tree-conflicts work should try not to change too many things.
This is something that we don't need to change, so I have made it
continue to work the way it did. (I did this on the
merge-skips-obstructions branch to fix merge_tests.py 27, and have now
merged the branch back to trunk.)

2. It is now coded and documented in the code as an explicit exception
to a general rule, which is easier to follow than when the rules were
coded completely separately for every case.

3. This exception was made for ease of use. In the tree conflicts work,
we are deeply involved with rules that catch all possible conflict
cases. For a sane software architecture, it is necessary to have such an
infrastructure that can detect all possible conflicts. However, on top
of that there needs to be a layer of user-interface behaviour that tries
to "do the Right Thing" as often as possible. I think that's what this
exception is for. (It's about "obstructions" rather than "conflicts" but
the same principle applies.) Now, it's encoded in the same software
layer whereas I would prefer to see the exception made in a higher
layer, so reflect the logical partitioning of the two concepts, but
that's how it is at the moment. We can go into the details of these
"ease of use" behaviours as a separate exercise.

- Julian

Received on 2008-12-03 13:06:13 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.