Alexis Huxley <ahuxley@gmx.net> writes:
> > > I checked the manual, man page, FAQ, but no info. I have an output
> > > from 'svn st -u -v' which contains the line:
> > >
> > > _ * 55 55 alexis ./bin/lspipe.spp
> > >
> > > My question is how do I interpret this? I'm confused why it tells
> > > me - after checking with the repos - that lspipe.spp was last
> > > changed in 55 but despite having 55 in my WC, that I still need
> > > to update.
> >
> > Those revisions numbers being displayed are cached in the entries
> > file. They're inserted whenever you do an update. When you update
> > your tree, at a *minimum* every single revision's working-rev is
> > bumped to HEAD. Files which get patched also have their 'last changed
> > rev' bumped.
>
> Sorry Ben, I don't follow. The '*' I get - it is right. But could you
> explain what the *second* '55' means? What use is it to me? Thanks.
OK, let me try a different explanation.
When you update your working copy to revision N, it downloads all
sorts of information. From then on, your working copy knows all sorts
of things about your files, but *only* up through revision N. It is
unable to know any information that is newer than revision N.
So when you run 'svn st -v', it shows you everything it knows. No
network is used. The first revision number is the revision of the
file that you have in your working copy. (Remember, it's easy to have
'mixed revision' working copies.) The second revision number is the
last revision in which the file changed. Of course, this number will
*always* be less than revision N, because the working copy doesn't
know about anything beyond revision N; it's just working off cached
data.
When you add the '-u' switch to 'svn st -v', it contacts the
repository and receives a list of paths that need to be patched.
That's it, nothing more. Then it puts an asterisk next to those
paths. It does *not* get a new value for the second revision number
-- although it definitely *could*. That number would be guaranteed to
be higher than the revision you have already (the first revnum).
Your expectation makes sense -- I mean, instead of just showing that
"this path needs updating", it might help to show the exact "future"
revision (> N) in which the file changes.
To answer your question directly: "what use is the second rev to me?"
It's just a way of looking into the past, that's all. Files don't
change in every revision, so it's nice to know the last revision in
which a file was changed, and who changed it. I can pass that number
to 'svn log' or 'svn diff' (although 'svn log/diff -rPREV' does the
same thing.)
Anyway, it sounds like your expectation is that when the '-u' switch
is added, that this 2nd number should let us peer into the *future*
instead of the past. Not a bad idea at all, really. Does anyone else
like it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 16:58:02 2002