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

Re: tree-conflicts: all tests

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 20 Oct 2008 15:03:58 +0100

On Sat, 2008-10-18 at 23:22 +0200, Neels J Hofmeyr wrote:
> So what is left to do?
>
> - Change test expectations to conflict on the victim, not on the parent
> (update, switch, merge, status, ...).
> - Change svn behaviour so that it complies.
> - Implement dirs_same_p(), inherently fix entire diff code.
> - Show status on missing tree conflict victims.
>
> What more do you have on your mind, what are you guys fixing right now?

The only other thing I know of is that we must be able to use merge to
help resolve a tree conflict, so probably there must be a way to merge
into a victim (especially a dir) that is marked as having a tree
conflict.

The two things I'm doing right now are:

  * Trying to get a grip on a sane UI for "svn diff --summarize" output.
It's not as simple as it sounded. Basically, I suggest: merge the
diff-repos-wc branch to trunk, concentrate on using the API, and let
other people comment on the UI.

  * A prototype "svn status --conflicts" command to show which nodes are
in conflict, with a brief indication of what incoming change conflicted
with what local change. This is something Stefan and I talked about a
few days ago as a better middle ground between the present "svn status"
and "svn info" reporting of conflicts. I'll post that so you can see.

> and still unanswered:
> >> Btw, what's the status of tree_conflict_tests.py?

It contains a bunch of tests that I have found helpful. I tried to be
too clever with the structure of the test code, and the result is too
difficult to understand, especially for anybody else but even for me
when not actively working on it. Most of it is covered by other tests
elsewhere. It's useful in that it collects together all the possible
scenarios, and (potentially) tests every aspect of each one (raising,
reporting, commit-blocking, resolving, ...).

In summary, I still want it for the time being, but anyone else can
ignore it if they want to, and I'll try to convert it into an
easier-to-follow form and/or decommision it later (when everything is
tested elsewhere).

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-20 16:04:35 CEST

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.