Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>
> 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.
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.
>
>>
>> #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)
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.
>
> (don't know)
Also fixed.
>
>>
>> - 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").
True.
>
>>
>> - 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?
Resolved doesn't yet contact the repo for anything.
resolved == resolve --accept=working
>
>> =====
>>
>> 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
>
>
>
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
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 09:33:01 CET