I (Julian Foad) wrote:
> > On Aug 27, 2010 11:33 AM, "Julian Foad" <julian.foad_at_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
Received on 2010-08-27 18:41:12 CEST