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