Making comments inline...
Julian Foad wrote:
> 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
That's related to #3161, but that's not mentioned in the issue.
> #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.
>
> #3320: Commit not blocked by tree conflict
This is very severe. Will try to look at this one next.
>
> #3161: Separate obstruction detection from tree conflict detection
This seems like it's still a blank spot on our map. It should be charted.
>
> #3162: use case 5 detection does not check whether victim is obstru
Isn't that the same as #3161 again?
>
> #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.
>
> #3211: Document how to resolve tree conflicts
Wow. When is that supposed to happen? How many cases are we covering?
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?
>
>
> =====
>
>>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.
>
> - Update and switch need to skip the final "cleanup" (setting the new
> revision, URL, etc) of items inside a tree-conflicted dir.
(don't know)
>
> - 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.
(don't know)
>
> - Update/switch fails if the target itself is a tree conflict victim.
> Should print a 'Skipped' message instead.
Low priority (unless it also happens when recursing to a TC victim, but I
take it it doesn't because you wrote "the target itself").
>
> - 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. It doesn't really break anything. Should be fixed though,
eventually, because it fails to mention a potential problem on the output.
>
>
> =====
>
>>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?
> =====
>
> 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.
Hey, that makes sense. Should be fairly quick to accomplish.
> =====
>
> 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
Wow, thanks for this summary, Julian.
~Neels
Received on 2008-11-18 03:55:30 CET