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

Re: Tree conflicts - What's To Do?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 18 Nov 2008 17:38:07 +0000

Thanks folks. I think we've now got all of this info in the issue
tracker with keyword "tree-conflicts".

Stephen Butler wrote:
> Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
> > Julian Foad wrote:
> >> =====
> >>
> >> Tracker items with target "1.6" or "1.6-consider" or "-". (To see all
> >> tree-conflicts issues in the tracker, search with
> >> "keywords"="tree-conflicts" at
> >> <http://subversion.tigris.org/issues/query.cgi>.)
> >>
> >> #3139: merge_tests.py 19 is XFail due to tree conflicts
> >
> > That's related to #3161, but that's not mentioned in the issue.

Thanks; it is now mentioned.

> >> #3209: Tests XFAIL due to changed tree-conflicts behaviour
> >
> > Fixing the test is lower priority, but knowing why each of the tests
> > mentioned fail (if they still do) is high priority.

Agreed, and mentioned in the issue.

> >> #3320: Commit not blocked by tree conflict
> >
> > This is very severe. Will try to look at this one next.

Thanks for fixing that, Neels. A couple of minor issues remain with it,
but no longer a severe issue.

> >> #3161: Separate obstruction detection from tree conflict detection
> >
> > This seems like it's still a blank spot on our map. It should be charted.
>
> FWIW, update now throws an error on obstruction, i.e., if entry->kind
> does not equal actually-on-disk kind. The merge code still treats this
> as a tree conflict.

I've just written in issue #3161 how I define the desired behaviour.
Steve has already done this for update/switch. For merge, it's
inconsistent.

> >> #3162: use case 5 detection does not check whether victim is obstru
> >
> > Isn't that the same as #3161 again?

Yes, it's a particular instance of it. Noted in the issue. Thanks.

> >> #2282: handle file delete/edit/add conflicts: tree changes and conf
> >> #2908: Improve behavior when tree conflicts are encountered during
> >> (These two are overviews of tree-conflicts handling.)
> >
> > Someone should check the numerous details and see if separate, more distinct
> > issues may spring from that.

> >> #3319: Allow merging into a tree-conflicted file
> >
> > This may be very important for usability. People may get very annoyed when
> > they have a situation where logic points at a merge but subversion plain
> > refuses.

You know what, I filed this issue a week ago to remind ourselves of it,
but I've just noted that it's only relevant if we try to block such
merges, and AFAIK we are not blocking them. So the issue is "Invalid" or
"Works for me". Confirm/deny?

> >> #3211: Document how to resolve tree conflicts
> >
> > Wow. When is that supposed to happen? How many cases are we covering?

When: 1.6 stabilisation time.

What: I would imagine something like this:

  * The dozen or so basic cases that affect just one node.
  * About two multi-conflict cases, like in a big update and a big
merge.
  * Any likely or interesting or difficult cases that don't fit the
above categories.

> > BTW, I was thinking that it would be nice to have some sort of super-matrix
> > of *all* *possible* tree-conflicts scenarios in high detail, with dimensions
> > as:
> > svn_cmd,
> > action,
> > reason,
> > action_type{prop, content, tree},
> > reason_type{prop, content, tree},
> > node_kind,
> > has_other_conflict,
> > has_persisting_tree_conflict,
> > parent_state{up-to-date|modified|missing...},
> > (and as many more as we can find...)
> > ...and somehow graphically represent when last anyone visited these cases,
> > whether they need to be considered, whether cmdline tests exist for it,
> > whether reverting/resolving/resolveding works and stuff. We are so often
> > listing single cases that are, at least to me, loosely scattered in space
> > instead of being nicely arranged into a bigger picture. Am I being naive?

I see what you mean but I don't know a way to represent the information
it so it remains manageable.

> >> =====
> >>
> >>> From "TODO-1.6":
> >>
> >> - "Most horrendous failure" during update: some logs are not executed
> >> when closing a dir.
> >> <http://svn.haxx.se/dev/archive-2008-11/0421.shtml>
> >
> > Will be fixed as soon as we agree on it.

That's issue #3328 "Update can't record >1 add/edit tree conflict per
dir".

> >> - Update and switch need to skip the final "cleanup" (setting the new
> >> revision, URL, etc) of items inside a tree-conflicted dir.
>
> Fixed.

> >> - Running 'svn status -u' fails (instead of showing '*' for pending
> >> update) when a switched item does not exist in the repo. Apparently
> >> due to the shoulda-skipped-cleanup bug above.
>
> Also fixed.

Thanks, Steve. Can we remove these from TODO-1.6?

> >> - Update/switch fails if the target itself is a tree conflict victim.
> >> Should print a 'Skipped' message instead.
> >
> > Low priority [...]

> >> - Update of an item that is inside a tree conflict, and that no longer
> >> exists in the repo, does nothing. Should print a 'Skipped' message
> >> instead.
> >
> > Lower priority. [...]

These two are issue #3329. Moved to a "non-essential issues" section of
TODO-1.6.

> >> =====
> >>
> >>> From current email threads:
> >>
> >> - A problem with adm_access and loggy writes and cached entries.
> > This is the same as above, where I said it will be fixed when we agree on it.
> >
> >> - Update/switch is going to be ugly because it doesn't update the
> >> base. User will have to undo local mods, "resolved", "update" again,
> >> then re-do local mods. I think.
> >
> > Won't "resolve" update to the new base? Can "resolved" do the same? I am
> > confused by resolve/resolved again. How well does "resolve" handle
> > tree-conflicts? What is "resolved" supposed to do?
>
> Resolved doesn't yet contact the repo for anything.
>
> resolved == resolve --accept=working

Potentially (and not in pre-1.6 time frame), we could design so that
"resolve[d]" contacts the repository to get the new base. Or so that
"update" fetches the new base but does not make it active, and
"resolve[d]" makes the new base active, i.e. actually "updates" the
base.

I don't see a good reason to do either of those, given that the model of
text and prop conflicts is that the "update" updates the base and then
the user has to resolve the working version. This model affects the
meaning of "diff" (BASE-to-WORKING) and "revert" and other stuff like
that, so I wouldn't want us to be inconsistent with that model.

> >
> >> =====
> >>
> >> What could we disable, in order to cut down the problem space?
[...]

Let's move discussion of what we could disable to another thread.

- 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-11-18 18:38:28 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.