On Thu, Feb 5, 2009 at 1:20 PM, Stephen Butler <sbutler_at_elego.de> wrote:
> Quoting Mark Phippard <markphip_at_gmail.com>:
>
>> Stephen,
>>
>> To clarify ...
>>
>> Group 3 is "done". Does that mean the test is no longer XFAIL? It
>> seemed like you just changed the description of the test from the
>> comments. But perhaps that was all Paul was pointing out needed to be
>> done. I guess my assumption with this issue is that when we are
>> "done" the tests will no longer be XFAIL.
>
> I just meant I had improved the cryptic output of the tests (in the
> docstrings).
>
> The XFAIL parts of that test are in fairly odd situations where the
> error message "A/B/C does not exist" takes precedence,
Hi Steve,
I don't follow the "not exist" part, is that still the case? All I
see failing in update_tests.py 50 is that the second updates don't
report that the tree conflicted paths under the update target are
skipped...
> or where the
> update output is silent. It'd be nice to say "A is tree-conflicted"
> in all of those situations, but it isn't a blocker.
...and if that all the problem is, then I agree this is not serious
enough to be a blocker.
> The skipping behavior is changing. We may have to revise this test
> soon anyway.
>
>>
>> You are working on groups 1 & 2. Do you think you'll be able to bring
>> these to completion? Any ideas on how much work is left/when it will
>> be completed?
>
> I'll commit the first part of the fix in a bit, if the tests are OK.
> Just making the add_file update code consistent with add_directory.
> This incidentally fixes some of the issue 3209 problems Paul
> mentioned.
>
> There's a day or two of work to do, so that update/switch will tolerate
> unversioned items and items added without history.
>
> But first I think we should eliminate skipping of newly discovered tree
> conflicts. Issue 3334 is more important, and involves the same code,
> so I'd like to get it out of the way first.
Issue #3334 is now out of the way, so #3209 is the last thing (other
than the Ruby bindings) standing between us and branching 1.6. If
there is any portion of this I can take on please let me know.
>> Group 4 ... what is your take on Paul's comments? Is this just an
>> area where there could be differences of opinion but it is working as
>> intended. Or is something broken and this is an item where more work
>> needs to be done?
>
> On looking more closely at merge_tests.py 20, I think the immediate
> issue Paul raised is a design question: should a missing item be
> flagged as a tree conflict by merge, or just notify the user that
> we skipped it? I tend toward the former.
I'm fine with the latter for 1.6 and seeing if users have any problems
with it. Why? As I said previously in this thread:
"Why is a tree conflict expected here? We report the files as skipped
during the merge and they show as missing in status. You can't even
commit the change without updating first to get the missing items
back. Yes, at that point you could commit and most likely you won't
have what you want in the repos, but you must willfully ignore a lot
of warnings that something is not quite right."
I don't see holding up 1.6 on this particular issue.
Paul
> In the source code, a
> comment suggests we simply update the missing items automatically,
> then continue the merge.
>
> But anyway, I see in libsvn_client/merge.c that our tree conflict
> detection code for handling missing and obstructing items is
> inconsistent in handling dirs and files.
>
> merge_dir_opened():
> unversioned or is-file or missing or unknown or deleted:
> -> "local delete, incoming edit upon merge"
>
> merge_file_opened():
> unversioned or is-dir or missing or unknown:
> -> "local missing, incoming edit upon merge"
>
> Looks like we need to clean up that code! After we sort out
> issues 3334 and 3209 for update/switch, I guess the next step
> is to sketch a table of how we handle each of these cases, to
> make sure the high-level design is implemented like we planned
> in /notes/tree-conflicts/*.txt.
>
> Steve
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1146703
Received on 2009-02-13 02:16:40 CET