Quoting Paul Burba <ptburba_at_gmail.com>:
> On Thu, Jan 22, 2009 at 11:20 AM, Stephen Butler <sbutler_at_elego.de> wrote:
>> Quoting Paul Burba <ptburba_at_gmail.com>:
[...]
>>> =======
>>> GROUP 3
>>> =======
>>>
>>> update_tests.py 50 'tree conflicts on update 2.3'
>>>
>>> This tests that updates of tree conflicted paths report the TCs as
>>> skipped, but what exactly does 2.3 refer to?
>>
>> To no other document. The names 2.1 and 2.2 are arbitrary, too.
>> Descriptive docstrings might help.
>>
>> tree conflicts 2.1 leaf edit, tree del on update
>> tree conflicts 2.2 leaf del, tree del on update
>> tree conflicts 2.3 skip TCs on 2nd update
>
> Ok, just wanted to be sure I wasn't missing some secret TC docs
> printed on the back of the Constitution :-)
> http://www.theonion.com/content/node/39384
>
>>> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases.txt
>>> has use case 2, but there are no subsections. This appears to be an
>>> test for issue #3329,
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=3329#desc2, and as
>>> I noted there, many of the cases this test covers now work and report
>>> skips:
>>>
>>> a) Directory tree conflict victim is updated
>>>
>>> b) File tree conflict victim is updated
>>>
>>> c) Directory within a tree conflict victim is updated
>>>
>>> d) Fle within a tree conflict victim is updated
>>> (file doesn't exist in the repos)
>>>
>>> What doesn't work is:
>>>
>>> e) A file within a tree conflict victim is updated
>>> (file doesn't exist in the repos but shows as
>>> locally added)
>>>
>>> f) Directory update target is not tree conflicted
>>> but has tree conflicted file child.
>>>
>>> g) Directory update target is not tree conflicted
>>> but has tree conflicted dir child.
>>>
>>> In all three of these cases the update prints no skip notifications,
>>> the 'At revision N.' is the only output. The status of the WC is the
>>> same in each case, so no harm is done outside of the missing skip
>>> notifications.
>>>
>>> So, is this simply a test for issue #3329 or is there anything else to
>>> consider?
>>
>> Yes, it's simply a regression test for #3329 "Update throws error when
>> skipping some tree conflicts".
>
> Is anyone working on e), f), and g)? I'm glad to take a look if not.
I'm pretty sure no one is looking at this issue now.
>
>>> =======
>>> GROUP 4
>>> =======
>>>
>>> merge_tests.py 20 'merge into missing must not break working copy'
>>>
>>> In r31326 (on the tree-conflicts branch) this test was changed to
>>> expect a tree conflict when merging into a directory that has a
>>> missing subtree (to be clear, this is missing in the '!' removed by a
>>> non-svn command sense of missing). The current (and pre-TC?) behavior
>>> was to report the missing subtrees as skipped.
>>>
>>> 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.
>>>
>>> This case mentioned in the 'SCENARIO PLAYGROUND' in
>>>
>>> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/scratch-pad.txt,
>>> but there is no conclusion:
>>>
>>> 'svn merge' pulls file modification atop missing file
>>>
>>> NOW: "Skipped missing target" message.
>>>
>>> NEW:
>>>
>>> There is also some mention of this in
>>>
>>> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/design-overview.txt
>>>
>>> * Pre-existing obstructions (status "~") or missing items ("!") should be
>>> detected first, before attempting to apply the change, and abort the
>>> operation.
>>>
>>> What is the latest thinking on this scenario?
>
> I know, people lose energy by the end of my mails, did you have any
> thoughts on this last item?
>
> Paul
This was a key use case for Philips Medical, when they decided to make
TruMerge to help detect tree conflicts. Happens very often when Java
developers refactor their designs.
To programmers who don't have to rename files to match their class
names, it's admittedly less important.
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-01-23 21:18:13 CET