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

Tree conflicts - What's To Do?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 17 Nov 2008 18:40:13 +0000

We all want to know what's left to do for tree conflicts. Here's the
best list I can make today. There are some obviously-blocking issues,
and there's lots more stuff we'd like to do but won't for 1.6, and there
are questions of usability.


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

#3139: merge_tests.py 19 is XFail due to tree conflicts
#3209: Tests XFAIL due to changed tree-conflicts behaviour

#3320: Commit not blocked by tree conflict

#3161: Separate obstruction detection from tree conflict detection

#3162: use case 5 detection does not check whether victim is obstru

#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.)

#3319: Allow merging into a tree-conflicted file

#3211: Document how to resolve tree conflicts


>From "TODO-1.6":

   - "Most horrendous failure" during update: some logs are not executed
     when closing a dir.

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

   - 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.

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

   - 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


>From current email threads:

   - A problem with adm_access and loggy writes and cached entries.

   - 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.


What could we disable, in order to cut down the problem space?

  * Cut the detection on update/switch; only handle merge. That would
remove a really big issue of how the "base" version should get updated
by update/switch. Merge is significantly simpler in that respect.


The idea of making this list is to be able to plan what to do for
stabilisation. I'm not sure how to make such a plan, but please help get
it started by commenting on the severity, effort and acceptability of
each of these, and add anything I've missed.

- 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-17 19:40:41 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.