Quoting Paul Burba <ptburba_at_gmail.com>:
> On Thu, Feb 5, 2009 at 1:20 PM, Stephen Butler <sbutler_at_elego.de> wrote:
>> Quoting Mark Phippard <markphip_at_gmail.com>:
>> 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...
The "not exist" part is no longer relevant. Since r34456, we don't
bother testing update deep inside local trees that no longer exist
in the repo. We may revisit this when wc-ng comes along.
>
>> 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.
OK.
>
>> The skipping behavior is changing. We may have to revise this test
>> soon anyway.
Actually we didn't change the skipping behavior for already-discovered
tree conflicts, so no effort is needed here.
>>
>>>
>>> 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.
I committed r35840 and r35842 today, which clean up the remaining
XFAILs noted in #3209.
I think we're out of the woods on this one now. I'm updating issue
3209 now. If there are no objections, I'll close it.
The only aspect I'm not 100% sure of is the following:
For "local add *without* history, incoming add via up/sw/co", we
neither raise a tree conflict nor stop with an error. Any
objections?
>
>>> 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
I agree. The commit is already blocked by the missing items, so adding
a tree conflict wouldn't gain much.
>
>> 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
I agree that the merge issues are not 1.6 blockers.
Steve
--
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
Received on 2009-02-13 15:23:22 CET