[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-10-09 05:54:59 CEST

Julian Foad <julianfoad@btopenworld.com> writes:

> C. Michael Pilato wrote:
> > Julian Foad <julianfoad@btopenworld.com> writes:
> >
> >>"svn status -u gone-dir" shows children of gone-dir as normal. They
> >>should have "!" status. (gone-dir exists in repository but has been
> >>deleted from the disk.)
> > Closed, WONTFIX. If gone-dir is missing from disk, we have no idea
> > a)
> > what revision that directory was at, b) that it even had children, and
> > c) what those children were. Without that knowledge, we can't presume
> > that children we learn about from the server also happen to be
> > children we used to have on disk but not do not (which is what
> > "missing" means).
> Er, well, in that case, how can it be correct that "svn status -u"
> lists all those children that it should know nothing about? Should
> it not either stop recursing or, if it does actually know about
> them, then show them as missing?

svn status -u isn't showing children of the missing thing. It's
showing children of an object in the repository that happens to have
the same name and children as the missing thing (in your particular
test-case). I *know* that reads like a cop-out answer, but trust me
-- I'm not trying to pull one over on you. Let me see if I can
demonstrate the difference:

   ### Checkout a fresh Greek repository, and cd into that working copy.
   $ svn co file://`pwd`/greek-repo wc
   A wc/A
   A wc/A/mu
   A wc/A/B
   Checked out revision 1.
   $ cd wc
   ### Now, remove A/D/H/chi and A/D/H/omega, and commit those removals.
   $ svn rm A/D/H/chi A/D/H/omega
   D A/D/H/chi
   D A/D/H/omega
   $ svn ci -m 'remove chi and omega'
   Deleting A/D/H/chi
   Deleting A/D/H/omega
   Committed revision 2.
   ### Update my working copy to HEAD (revision 2), but then backdate
   ### A/D/H to revision 1
   $ svn up
   At revision 2.
   $ svn up -r1 A/D/H
   A A/D/H/chi
   A A/D/H/omega
   Updated to revision 1.
   ### 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.

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

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

Does that make sense to you?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 9 05:56:05 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.