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

RE: status cmd in mixed-rev nested copies

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 4 Jun 2011 00:54:35 +0200

> -----Original Message-----
> From: Stephen Butler [mailto:sbutler_at_elego.de]
> Sent: zaterdag 4 juni 2011 0:07
> To: Subversion Development
> Subject: status cmd in mixed-rev nested copies
>
> Hello WC-NG gurus,
>
> I ran into a strange problem while working on issue 3899 "auto-resolve
> conflicts at wc-wc copy/move destination". The 'svn status' command
> and the entries-dump utility (for 1.6 compatibility) disagree.
>
> See stat_tests.py 35 for details. It's quite short, so I'll paste it into
this
> message.
>
> According to notes/api-errata/1.7/wc003.txt, nested copies that lead to
> mixed revisions should be elided in the UI, because Subversion should
> handle mixed revisions without ceremony. That's what entries-dump
> does.

I think this specific errata was written long before we introduced the NODES
table, so some of this might (and probably is) be out of date.

Mixed revision copies introduce multiple new layers now. Whenever a child
has a different revision then its parent a not-present child is inserted at
the parent's op-depth and a new layer is created for the node itself.
(This matches exactly what you would see at a commit. In 1.6 the commit
harvester had to find all this information itself).

svn_wc_entry_t can't express multiple layers and just shows what the client
would have seen for a similar operation in 1.6. In 1.6 the only difference
you would see is that the copyfrom revision is different and other users of
this information had to do the hard work themselves.

Entries-dump is just writing out what is inside svn_wc_entry_t; status
provides what we really know.

> But IMHO the op_root of a nested copy destination should have
> svn_wc_status_added (and copied) instead of svn_wc_status_normal
> (and copied). Otherwise, how can the user tell where 'svn revert' is
> permitted? I think we need to fix entries-dump and update the errata.

This case is not unique in our testsuite. The way to fix this test is:

Index: dev/subversion/tests/cmdline/stat_tests.py
===================================================================
--- dev/subversion/tests/cmdline/stat_tests.py (revision 1131272)
+++ dev/subversion/tests/cmdline/stat_tests.py (working copy)
@@ -1890,6 +1890,9 @@

   # Note: A "local edit, incoming delete upon update" tree conflict
   # leads to the same situation.
+
+ # BH: But this tree conflict scenario gets into this situation via a
+ # completely different and not nearly as well tested code-path.

   sbox.build()
   wc = sbox.ospath
@@ -1906,14 +1909,11 @@
   sbox.simple_mkdir('copy-dest')
   sbox.simple_copy('A/D', 'copy-dest')

- ### As of r1130919 (pre-1.7 trunk): If we expect status ' ' for D/G,
- ### the verification via 'svn status -vuq' fails. If we expect
- ### status 'A ', the verification via 'entries-dump' fails. Which
- ### one is right?
   expected_status = svntest.wc.State(wc('copy-dest'), {
     '' : Item(status='A ', wc_rev=0),
     'D' : Item(status='A ', copied='+', wc_rev='-'),
- 'D/G' : Item(status=' ', copied='+', wc_rev='-'), # <---
+ 'D/G' : Item(status='A ', copied='+', wc_rev='-',
+ entry_status=' '),
     'D/G/pi' : Item(status=' ', copied='+', wc_rev='-'),
     'D/G/rho' : Item(status=' ', copied='+', wc_rev='-'),
     'D/G/tau' : Item(status=' ', copied='+', wc_rev='-'),

This tells the test-suite that the status and the schedule stored in the
entries is not the same. (There is also an entry_rev argument for when the
revisions don't match. You can find this related problem in some replaced by
addition scenarios, but not on copies. For additions entries sometimes show
the revision of the replaced node, while for copies the revision is
updated).

        Bert
Received on 2011-06-04 00:55:13 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.