On Fri, Feb 13, 2009 at 9:22 AM, Stephen Butler <sbutler_at_elego.de> wrote:
> 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?
I think we need to change this. Last night in IRC Mark raised this
very issue, specifically the case where a file add is obstructed by a
file added without history where the files have text conflicts. He
expected a tree conflict in this case. Prior to merging the issue
3334 branch to trunk we did get a tree conflict(1):
PRE3334.DBG>svn st -v update_tests-34.backup\A\D
1 1 jrandom update_tests-34.backup\A\D
1 1 jrandom update_tests-34.backup\A\D\gamma
1 1 jrandom update_tests-34.backup\A\D\G
1 1 jrandom update_tests-34.backup\A\D\G\pi
1 1 jrandom update_tests-34.backup\A\D\G\rho
1 1 jrandom update_tests-34.backup\A\D\G\tau
1 1 jrandom update_tests-34.backup\A\D\H
1 1 jrandom update_tests-34.backup\A\D\H\chi
1 1 jrandom update_tests-34.backup\A\D\H\omega
1 1 jrandom update_tests-34.backup\A\D\H\psi
A 0 ? ? update_tests-34.backup\A\D\epsilon
PRE3334.DBG>svn log -r2 -v -q update_tests-34.backup
------------------------------------------------------------------------
r2 | jrandom | 2009-02-13 09:47:36 -0500 (Fri, 13 Feb 2009)
Changed paths:
A /A/D/epsilon
------------------------------------------------------------------------
PRE3334.DBG>svn up update_tests-34.backup\A\D
C update_tests-34.backup\A\D\epsilon
At revision 2.
Summary of conflicts:
Tree conflicts: 1
===CASE A===
With trunk_at_35842, as you point out, there is no tree conflict nor any error:
trunk.dbg>svn up update_tests-34.backup\A\D
Conflict discovered in 'update_tests-34.backup/A/D/epsilon'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
C update_tests-34.backup\A\D\epsilon
Updated to revision 2.
Summary of conflicts:
Text conflicts: 1
trunk.dbg>svn st -v update_tests-34.backup\A\D
2 2 jrandom update_tests-34.backup\A\D
? update_tests-34.backup\A\D\epsilon.mine
? update_tests-34.backup\A\D\epsilon.r0
? update_tests-34.backup\A\D\epsilon.r2
2 1 jrandom update_tests-34.backup\A\D\gamma
2 1 jrandom update_tests-34.backup\A\D\G
2 1 jrandom update_tests-34.backup\A\D\G\pi
2 1 jrandom update_tests-34.backup\A\D\G\rho
2 1 jrandom update_tests-34.backup\A\D\G\tau
2 1 jrandom update_tests-34.backup\A\D\H
2 1 jrandom update_tests-34.backup\A\D\H\chi
2 1 jrandom update_tests-34.backup\A\D\H\omega
2 1 jrandom update_tests-34.backup\A\D\H\psi
C 2 2 jrandom update_tests-34.backup\A\D\epsilon
===CASE B===
If there are no text differences between the two files then we report
the added obstruction as 'E'xisting:
trunk.dbg>svn up update_tests-34.backup\A\D
E update_tests-34.backup\A\D\epsilon
Updated to revision 2.
trunk.dbg>svn st -v update_tests-34.backup\A\D
2 2 jrandom update_tests-34.backup\A\D
2 1 jrandom update_tests-34.backup\A\D\gamma
2 1 jrandom update_tests-34.backup\A\D\G
2 1 jrandom update_tests-34.backup\A\D\G\pi
2 1 jrandom update_tests-34.backup\A\D\G\rho
2 1 jrandom update_tests-34.backup\A\D\G\tau
2 1 jrandom update_tests-34.backup\A\D\H
2 1 jrandom update_tests-34.backup\A\D\H\chi
2 1 jrandom update_tests-34.backup\A\D\H\omega
2 1 jrandom update_tests-34.backup\A\D\H\psi
2 2 jrandom update_tests-34.backup\A\D\epsilon
I agree with Mark that CASE A should be a tree conflict, and the
incoming file's text should simply be replaced by the locally added
file's text rather than being merged. This essentially maintains the
old obstruction tolerance functionality added in r22257 but adds a
tree conflict to attract the user's attention that something might be
amiss.
It's a bit trickier with case B, the existing behavior of not raising
a tree conflict is quite nice, but at first glance this does not
appear very straightforward...looking a bit deeper right now.
Does this sound like a reasonable approach?
Paul
~~~~~
(1) Before the 3334 branch was merged back to trunk things didn't work
quite so well:
Turns out epsilon is still scheduled for addition, and a revert or
resolve shows it as unversioned!
PRE3334.DBG>svn st -v update_tests-34.backup\A\D\epsilon
A C 0 ? ? update_tests-34.backup\A\D\epsilon
> local add, incoming add upon update
PRE3334.DBG>svn revert -R update_tests-34.backup\A\D\epsilon
Reverted 'update_tests-34.backup\A\D\epsilon'
PRE3334.DBG>svn st -v update_tests-34.backup\A\D\epsilon
? update_tests-34.backup\A\D\epsilon
PRE3334.DBG>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1151565
Received on 2009-02-13 16:50:05 CET