[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help on 1.6-blocker #3334 - tree conflicts in update

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 30 Jan 2009 17:58:58 -0500

On Wed, Jan 28, 2009 at 3:48 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Blocker:
>>
>> * #3334: Tree conflicts "merry-go-round" about update updating the base.
>> Julian Foad is working on this. Done for when victim is a file, still
>> doing for when victim is a directory. [julianfoad]
>> See: <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1019712>.
>
> I'm struggling with this and could use some help. I have rather little
> time to look at it these days.
>
> On the issue-3334-dirs branch, the remaining problem is "just" a matter
> of scheduling a directory tree to be re-added as a copy of what it was
> before.
>
> The function "schedule_existing_item_for_re_add()" tries to do this, but
> doesn't get the result quite right.
>
> On the branch I added a new "test" (update_tests.py 53). This "test"
> doesn't actually test anything, but just runs the tree-conflict
> scenario, and also runs a manual schedule-as-re-add command sequence, so
> that we can (manually) compare the resulting "entries" files.
>
> In test 53, the tree conflict victim is directory A/ and A's THIS_DIR
> entry needs a "revision" of 1, but it gets a revision of 2. That's all
> that is wrong with its THIS_DIR entry. There is nothing wrong with its
> children, I think. The only other problem is A's entry in its parent,
> which gets several fields wrong (different from the "manual copy" WC).
>
> Please could someone have a look at the differences between the entries
> files in test 53's two WCs, and see how to make
> "schedule_existing_item_for_re_add()" create that state.

Julian (and/or any other TCers),

I've got this test working, but I'm wondering about a slightly
different case than the one covered in the test.

What if, instead of having a modification directly to the directory
that the update will attempt to delete, we instead have a local mod
only to a subtree of that directory? For example, say we start with
this vanilla Greek WC:

    issue3334.dgb>svn st -v
                     1 1 jrandom .
                     1 1 jrandom A
                     1 1 jrandom A\B
                     1 1 jrandom A\B\lambda
                     1 1 jrandom A\B\E
                     1 1 jrandom A\B\E\alpha
                     1 1 jrandom A\B\E\beta
                     1 1 jrandom A\B\F
                     1 1 jrandom A\mu
                     1 1 jrandom A\C
                     1 1 jrandom A\D
                     1 1 jrandom A\D\gamma
                     1 1 jrandom A\D\G
                     1 1 jrandom A\D\G\pi
                     1 1 jrandom A\D\G\rho
                     1 1 jrandom A\D\G\tau
                     1 1 jrandom A\D\H
                     1 1 jrandom A\D\H\chi
                     1 1 jrandom A\D\H\omega
                     1 1 jrandom A\D\H\psi
                     1 1 jrandom iota

Then we delete 'A' directly in the repos:

    issue3334.dgb>svn del %url53%/A -m ""

    Committed revision 2.

Then we make a text mod in our WC to a subtree of 'A':

    issue3334.dgb>echo new content > A\D\G\pi

    issue3334.dgb>svn up
       C A
    At revision 2.
    Summary of conflicts:
      Tree conflicts: 1

Ok, the tree conflict is correct, but what should be scheduled for
addition? Should the entire subtree rooted at 'A' be schedule for
addition as a copy from A_at_1?

    issue3334.dgb>svn st -v
                 2 2 pburba .
    A + C - 1 jrandom A
> local edit, incoming delete upon update
       + - 1 jrandom A\B
       + - 1 jrandom A\B\lambda
       + - 1 jrandom A\B\E
       + - 1 jrandom A\B\E\alpha
       + - 1 jrandom A\B\E\beta
       + - 1 jrandom A\B\F
       + - 1 jrandom A\mu
       + - 1 jrandom A\C
       + - 1 jrandom A\D
       + - 1 jrandom A\D\gamma
       + - 1 jrandom A\D\G
    M + - 1 jrandom A\D\G\pi
       + - 1 jrandom A\D\G\rho
       + - 1 jrandom A\D\G\tau
       + - 1 jrandom A\D\H
       + - 1 jrandom A\D\H\chi
       + - 1 jrandom A\D\H\omega
       + - 1 jrandom A\D\H\psi
                     2 1 jrandom iota

*OR* should only the modified subtree 'A/D/G/pi' and its path-wise
ancestors be present?

    issue3334.dgb>svn st -v
                 2 2 pburba .
    A + C - 1 jrandom A
> local edit, incoming delete upon update
       + - 1 jrandom A\D
       + - 1 jrandom A\D\G
    M + - 1 jrandom A\D\G\pi

                     2 1 jrandom iota

I've got the former working*, but I wonder if the latter is not
actually the correct behavior.

Opinions appreciated,

Paul

* Though not quite ready as several update and switch tests are now failing.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1077047
Received on 2009-01-30 23:59:20 CET

This is an archived mail posted to the Subversion Dev mailing list.