Tree conflicts - What's To Do?

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
<http://subversion.tigris.org/issues/query.cgi>.)

#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.
     <http://svn.haxx.se/dev/archive-2008-11/0421.shtml>

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

=====

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

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