On Thursday 09 October 2003 17:22, C. Michael Pilato wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > I understand the fact that we don't know what revision the directory
> > was at. I guess my issue is that we're making an assumption
> > here... and it's even stated by the status function (Status against
> > revision: 2). In this case, we know for a fact that A/D/H/psi
> > doesn't exist in the WC because A/D/H doesn't. I find it a bit
> > disturbing that 'svn st -u' in some way indicating that it is in our
> > working copy (because it isn't being flagged as missing).
>
> Hm. I guess I can see the concern, but besides that fact that this
> thread has now gone beyond the informative and moved on into the
> nit-picky, I say we just trust our users to be smart enough to realize
> that if a directory is missing from disk, its children are also not
> present.
I can agree with that to an extent... I believe the tool should ultimately
indicate the right thing though. :-)
> > > "Missing" means "I *know* I'm supposed to have this in my working
> > > copy, but for some reason I don't." psi doesn't meet the criteria
> > > here, because we *don't* know that we're supposed to have it -- we
> > > have absolutely no client-side record of it ever existing.
> >
> > Again, we've made an assumption, that we're taking the status
> > against rev 2.
>
> Um. No.
>
> We've made the declaration that running '-u' *means* we are running
> status again HEAD. Who needs to assume?
I'm sorry, I should've stated that better. That's exactly what I meant. In
the 'svn st -u' case we've indicated what we're checking against, and since
we know that A/D/H/psi should be there and isn't, it should be flagged as
missing.
I don't think this is a big deal... I realize it is nit picky (not that this
group in unfamiliar with that :-), not needed for 1.0, and probably more
trouble than it's worth to fix. But again, it doesn't necessarily match what
the union of 'svn st' and 'svn up'.
I'll stop bothering you now. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 10 02:11:11 2003