> 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* !
> > 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:13:05 CEST