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

Re: svn commit: rev 1895 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/svntest

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-05-08 01:15:40 CEST

Karl Fogel wrote:
> Nuutti Kotivuori <naked@iki.fi> writes:
>> Well that works quite fast ofcourse - but that brings me back to
>> the same problem - I only see the new revision, not the revision
>> that my wc is currently at. That is assuming ofcourse nothing
>> changed under the current working directory.
> It's that last sentence I don't understand.

Sorry, it was written in a hurry. I'll try to be clearer.

> Do you mean local changes, the kind that would be committed if you
> ran "svn ci"? Or do you mean the case where your working copy is a
> mixture of various revisions, instead of all being at the same
> revision as (say) the directory you're running "svn st" or "svn up"
> in?

Let's assume a case where I have only /trunk/ checked out as my
working copy. The somebody does a commit under /branch/

What I would see if I would type 'svn up' would be this:
| naked@oro:~/src/subversion/svn$ svn up
| At revision 1901.

Just silently updating my working copy to revision 1901, so I do not
even notice that it was not already revision 1901. There's is no harm
in updating to revision 1901 what so ever, but I would like to *know*
about it.

What I would see if I would type 'svn st -u' instead:
| naked@oro:~/src/subversion/svn$ svn st -u
| Head revision: 1901

Again, I do not notice anything changed - since nothing changed under
my working directory - but now my working copy is not modified.

But, if I type 'svn st -u README':
| naked@oro:~/src/subversion/svn$ svn st -u README
| __ 1900 README
| Head revision: 1901

Here is the only place I see what I want - the working copy right now
is at revision 1900 (or atleast that file of it) - and that the
repository head is at 1901. I see this without anything changing under
my working directory.

This last case is what I would like to accomplish, hopefully even
without me comparing those two numbers myself, but the program doing
it for me. And hopefully without picking a random file from the
working copy.

> The phrase "the revision that my wc is currently at" is meaningless,
> except when your wc all happens to be at one revision, or reflect
> the content of one revision -- but to determine that, the entire wc
> still has to be crawled by the client.

Yes, but if I run 'svn up' - after that all of the working copy is at
the same revision (not considering disjoint working copies etc.).

>> Well that is exactly what I do, in the end. And the only thing
>> running 'svn up' is lacking right now, for me, is that it would
>> give some sort of a clue that the revision number got bumped, even
>> though there were no changes to the directory you ran 'svn up' in.
> Yeah. I still don't see how it helps your stated goal to see
> whether revision number got bumped or not, though...

'svn up' on a working copy which gets updated to the latest version,
even though there are no changes to the files:
| naked@oro:~/src/subversion/svn$ svn up
| Now at revision 1901.

'svn up' on a working copy which is already the current revision[1]:
| naked@oro:~/src/subversion/svn$ svn up
| Already at revision 1901.

But this is all just my way of thinking, really - it doesn't seem like
others have the same problem - so you can just as well ignore the
problem. I know I will unless something concrete comes out of this

-- Naked


[1] I understand that it cannot be said that a working copy would be
"at a revision", since the revisions of files under it can differ. But
for me, it would even suffice to see if the current directory revision

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 8 01:17:13 2002

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.