On Mar 24, 2005, at 10:24 PM, C. Michael Pilato wrote:
> Soothing my specific concerns might be as simply as 'svn info' making
> clear (preferably in its output, but I suppose its usage message would
> be okay) that the information it reports about working copy paths is
> limited in scope to what the working copy knows at the time, and that
> is very possible that the information could be stale (and therefore
> unreliable). I mean, maybe we just need to put asterisks by the field
> names which could possible be stale (the lock stuffs, revision
> author/date stuff, etc.) like footnotes about their reliability.
I don't understand why this is a problem. Should 'svn info wcpath'
also place asterisks next to 'last-changed-rev/author/date', because,
well, somebody might have changed the file in the repository? Yes,
that's a reasonable comparison. They're both ways in which a
working-copy can be "out of date".
I think we're making a mountain out of a molehill. Users *know* that
running info on a working-copy object doesn't contact the server. They
know that they're looking at whatever the working copy knows. They
know that running 'svn up' might change much of that information.
$ svn info blah
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Node Kind: file
Last Changed Author: sussman
Last Changed Rev: 13
Last Changed Date: 2005-03-16 14:48:29 -0600 (Wed, 16 Mar 2005)
Text Last Updated: 2005-03-24 14:31:59 -0600 (Thu, 24 Mar 2005)
Properties Last Updated: 2005-03-24 14:31:59 -0600 (Thu, 24 Mar 2005)
Lock Token: opaquelocktoken:0b125931-23f3-0310-9a23-8d49dad577c8
Lock Owner: sussman
Lock Created: 2005-03-25 07:30:07 -0600 (Fri, 25 Mar 2005)
Lock Comment (1 line):
Are you *really* worried that the lock-owner, lock-creation-date, and
lock-comment are going to change behind the locker's back? That seems
about as likely as someone editing the svn:author or svn:date property.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Mar 25 14:40:29 2005