I (Julian Foad) wrote:
> > On Aug 27, 2010 11:33 AM, "Julian Foad" <julian.f...@wandisco.com> wrote:
> > > In single-DB world, the WC generated in merge_tests.py 16, a directory
> > > 'A/B/F/Q' has been deleted from disk without informing Subversion, so
> > > its status is 'missing'.
> > >
> > > Look at the difference between these two "svn status" runs on it:
> > >
> > > $ svn st A/B/F -vu
> > > ! 2 2 jrandom A/B/F/Q
> > > ! 2 2 jrandom A/B/F/foo
> > > 1 1 jrandom A/B/F
> > > Status against revision: 3
> > >
> > > $ svn st A/B/F -v
> > > 1 1 jrandom A/B/F
> > > ! 2 2 jrandom A/B/F/Q
> > > ! 3 3 jrandom A/B/F/Q/R
> > > ! 3 3 jrandom A/B/F/Q/R/bar
> > > ! 3 3 jrandom A/B/F/Q/baz
> > > ! 2 2 jrandom A/B/F/foo
> > >
> > > In the old multi-DB WC world, status was not able to recurse into a
> > > missing directory because the metadata's unavailable, so it didn't,
> > > neither in local mode nor in '-u' mode. (In '-u' mode of course it
> > > could find out what children of 'Q' are in the repo, but it didn't.)
> 
> Oops: apparently in multi-DB mode it *did* recurse in -u mode, but not
> in local mode, and both parts of this behaviour is tested by
> stat_tests.py 20.
> 
> In single-DB mode, currently it does the *opposite* !

Rats!  Does it?  I'm all confused.  In stat_tests 20, normal (multi-DB)
trunk build recurses only with '-u':

[[[
$ for FLAGS in '' '-u' '-v' '-vu'; do (cd 
obj-dir/subversion/tests/cmdline/svn-test-work/working_copies/ && echo svn st 
$FLAGS && svn st $FLAGS stat_tests-20/A/D/G); done
svn st
!       stat_tests-20/A/D/G
svn st -u
        *            stat_tests-20/A/D/G/rho
        *            stat_tests-20/A/D/G/pi
        *            stat_tests-20/A/D/G/tau
!       *       ?    stat_tests-20/A/D/G
Status against revision:      1
svn st -v
!               ?        ?   ?           stat_tests-20/A/D/G
svn st -vu
        *                                stat_tests-20/A/D/G/rho
        *                                stat_tests-20/A/D/G/pi
        *                                stat_tests-20/A/D/G/tau
!       *       ?        ?   ?           stat_tests-20/A/D/G
Status against revision:      1
]]]

and single-DB build recurses always:

[[[
$ for FLAGS in '' '-u' '-v' '-vu'; do (cd 
obj-dir/subversion/tests/cmdline/svn-test-work/working_copies/ && echo svn st 
$FLAGS && svn st $FLAGS stat_tests-20/A/D/G); done
svn st
!       stat_tests-20/A/D/G
!       stat_tests-20/A/D/G/rho
!       stat_tests-20/A/D/G/pi
!       stat_tests-20/A/D/G/tau
svn st -u
!                1   stat_tests-20/A/D/G/rho
!                1   stat_tests-20/A/D/G/pi
!                1   stat_tests-20/A/D/G/tau
!                1   stat_tests-20/A/D/G
Status against revision:      1
svn st -v
!                1        1 jrandom      stat_tests-20/A/D/G
!                1        1 jrandom      stat_tests-20/A/D/G/rho
!                1        1 jrandom      stat_tests-20/A/D/G/pi
!                1        1 jrandom      stat_tests-20/A/D/G/tau
svn st -vu
!                1        1 jrandom      stat_tests-20/A/D/G/rho
!                1        1 jrandom      stat_tests-20/A/D/G/pi
!                1        1 jrandom      stat_tests-20/A/D/G/tau
!                1        1 jrandom      stat_tests-20/A/D/G
Status against revision:      1
]]]

Note also that single-DB prints status '!' for children, whereas it
didn't used to.

Now look at merge_tests 16.  Multi-DB (trunk build) recurses only with
'-u':

[[[
$ for FLAGS in '' '-u' '-v' '-vu'; do (cd 
obj-dir/subversion/tests/cmdline/svn-test-work/working_copies/ && echo svn st 
$FLAGS && svn st $FLAGS merge_tests-16/A/B/F/Q); done
svn st
!       merge_tests-16/A/B/F/Q
svn st -u
        *            merge_tests-16/A/B/F/Q/R/bar
        *            merge_tests-16/A/B/F/Q/R
        *            merge_tests-16/A/B/F/Q/baz
!       *       ?    merge_tests-16/A/B/F/Q
Status against revision:      3
svn st -v
!               ?        ?   ?           merge_tests-16/A/B/F/Q
svn st -vu
        *                                merge_tests-16/A/B/F/Q/R/bar
        *                                merge_tests-16/A/B/F/Q/R
        *                                merge_tests-16/A/B/F/Q/baz
!       *       ?        ?   ?           merge_tests-16/A/B/F/Q
Status against revision:      3
]]]

and single-DB recurses only WITHOUT '-u' !!!

[[[
$ for FLAGS in '' '-u' '-v' '-vu'; do (cd 
obj-dir/subversion/tests/cmdline/svn-test-work/working_copies/ && echo svn st 
$FLAGS && svn st $FLAGS merge_tests-16/A/B/F/Q); done
svn st
!       merge_tests-16/A/B/F/Q
!       merge_tests-16/A/B/F/Q/R
!       merge_tests-16/A/B/F/Q/R/bar
!       merge_tests-16/A/B/F/Q/baz
svn st -u
!                2   merge_tests-16/A/B/F/Q
Status against revision:      3
svn st -v
!                2        2 jrandom      merge_tests-16/A/B/F/Q
!                3        3 jrandom      merge_tests-16/A/B/F/Q/R
!                3        3 jrandom      merge_tests-16/A/B/F/Q/R/bar
!                3        3 jrandom      merge_tests-16/A/B/F/Q/baz
svn st -vu
!                2        2 jrandom      merge_tests-16/A/B/F/Q
Status against revision:      3
]]]

Note: these 'svn st' commands were run after stopping merge_tests 16
just after it removes 'foo' and 'Q' from disk, before it attempts any
merges.

What's the difference between the WCs of stat_tests 20 and merge_tests
16?  I suspect it's to do with the mixed-rev nature of the latter.

Will investigate on Tuesday.

I suggest we should review any adjustments we've made to test
expectations on 'status' output.  stat_tests 20 was tweaked to pass in
r980774, but I don't think we've really decided what should change and
what should stay the same.

We should write UI change notes, similar to notes/api-errata/*, for
deliberate UI changes.


> > > Now, in single-DB, it can report the whole WC status. But should it?
> > >
> > > I don't know whether to make it stop there (for back compat?) or
> > > recurse. Either way, the current inconsistency is, I think, wrong.
> 
> Greg Stein wrote:
> > Recurse. Show all the info.
> 
> Can I make it do what it did before, at least for now?
> 
> Stefan Küng wrote:
> > I would say if -u is given, it should recurse. If it's not set, then 
> > there's no need to recurse because all subitems have the same missing 
> > state as the deleted folder.
> 
> If we schedule a dir for deletion, "status" shows all the contents of
> that dir separately, so I don't know that "all have the same state" is
> an argument.


- Julian


Reply via email to