[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Miscellaneous bugs

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-10-09 23:01:37 CEST

On Thursday 09 October 2003 08:22, you wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > On Wednesday 08 October 2003 23:54, C. Michael Pilato wrote:
> > [...]
> >
> > > ### Now, oops! I removed A/D/H (at revision 1, remember) from disk
> > > $ rm -rf A/D/H
> > >
> > > ### Now I run status.
> > > $ svn st -u A/D/H
> > > * A/D/H/psi
> > > ! * ? A/D/H
> > > Status against revision: 2
> > >
> > > Now, the first thing to notice is that only H is reported as missing.
> > > Why? Because this is the only thing we actually know about that is
> > > missing. There is *no record* in the working copy that we had H at
> > > revision 1 before its untimely demise. It could have been at any
> > > revision. If this display showed chi and omega as missing, well that
> > > would just be wrong, because they weren't supposed to be in the
> > > working copy.
> >
> > Sorry for jumping in, but I saw something that I didn't understand. You
> > removed the A/D/H directory completely... so why does your 'svn st -u
> > A/D/H' command show A/D/H/psi as *not* missing?
>
> If H is missing from disk (and therefore, with it, it's .svn/ admin
> subdir and all information housed therein), we have no idea what
> version H was at (since that's stored in H/.svn/entries, now missing)
> and what children it had (also stored in the missing entries file).

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).

> > > So, what does 'svn status -u' really mean? It means, quite literally,
> > > show me the union of a) my working copy status and b) what I would
> > > see modified if I ran 'svn update' right now. And indeed, this is
> > > what I see. Running just 'svn status A/D/H' shows just this missing
> > > A/D/H:
> > >
> > > $ svn st A/D/H
> > > ! A/D/H
> > >
> > > And what would get touched if I updated right now? Well, let's see:
> > >
> > > $ svn up A/D/H
> > > A A/D/H
> > > A A/D/H/psi
> > > Updated to revision 2.
> > >
> > > As you can see, the union of these two operations is exactly what 'svn
> > > st -u A/D/H' shows.
> >
> > Here the update command added both A/D/H and A/D/H/psi. I would've
> > expected that either the 'svn st -u' command would've shown both as
> > missing or only A/D/H as missing and not even mention A/D/H/psi.
> > Considering the fact that you said it was the union of a) and b), I would
> > expect both to be listed as missing.
> >
> > Am I missing something here too? :-)
>
> Yup. The point, I'm sorry to say. :-)
>
> "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.
In this case, we do know that it's supposed to be there and isn't. I can see
this is very edge-case situation with having mixed revision and not knowing
what revision A/D/H should be at. But if this really is supposed to be a
union of what you get with a 'svn st' and what would be updated by 'svn up',
then I believe A/D/H/psi should be flagged as missing because we made an
assumption about what revision it should be at.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 9 22:59:07 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.