You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2010/08/27 15:32:18 UTC
Single-DB: should "status -u" recurse into missing dir?
(merge_tests 16 failure)
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.)
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.
Any insight?
- Julian
Re: Single-DB: should "status -u" recurse into missing dir? (merge_tests
16 failure)
Posted by Stefan Küng <to...@gmail.com>.
On 27.08.2010 17:32, Julian Foad 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.)
>
> 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.
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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Single-DB: should "status -u" recurse into missing dir?
(merge_tests 16 failure)
Posted by Julian Foad <ju...@wandisco.com>.
I (Julian Foad) wrote:
> > On Aug 27, 2010 11:33 AM, "Julian Foad" <ju...@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
Re: Single-DB: should "status -u" recurse into missing dir?
(merge_tests 16 failure)
Posted by Julian Foad <ju...@wandisco.com>.
> On Aug 27, 2010 11:33 AM, "Julian Foad" <ju...@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* !
> > 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
Re: Single-DB: should "status -u" recurse into missing dir?
(merge_tests 16 failure)
Posted by Greg Stein <gs...@gmail.com>.
Recurse. Show all the info.
On Aug 27, 2010 11:33 AM, "Julian Foad" <ju...@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.)
>
> 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.
>
> Any insight?
>
> - Julian
>
>