On 14 Sep 2001 09:40:49 -0500
Ben Collins-Sussman <sussman@collab.net> wrote:
> I don't feel like this is such a bikeshed discussion anymore; people
> seem to be very worried about choosing bad UI defaults... they really
> want Subversion to get it Right, based on past annoying experiences
> with CVS's UI.
...
> In cases 1 and 2, where the network is not accessed, a status
> line would look like:
>
> M 58 [ -] ( -) foo.c
>
> In cases 3 and 4, where update info is fetched, a status line
> would have all the numbers filled in:
>
> M 58 [ *59] ( 60) foo.c
>
>
> I know that in case 1, some people would really like to see the
> revision fields go; but I feel strongly about *not* changing
> the way status lines look based on switches.
I don't really see a problem with optionally providing a more detailed
output based on command line switches. What bothers me about this
proposal is that it seeks to display an additional version number in an
already number heavy status line. We have already discussed the
marginal usefulness of printing the HEAD server revision in each line.
Printing an additional number indicating what revision the given
file changed on the server seems even less useful.
What does this output tell us?
% svn status foo.c
M 58 [ *70] ( 75) foo.c
It says foo.c is currently at rev 58 and that the server is at rev 75. It also
says that foo.c last changed at rev 70 and will be patched during the
next update. Is this patch version number information really so useful
that it should be displayed by default? What if revisions 60 -> 70 were
all changes to foo.c? The 3 rev status output is not going to tell us that.
One possible argument is that the middle rev number could be used
to look at a diff before actually pulling it down with and update.
% svn status foo.c
M 58 [ *70] ( 75) foo.c
% svn diff -r 58 -r 70 foo.c
Of course, the user could get the same info by doing a diff from the
current rev to the HEAD rev, so that does not buy us much.
% svn status foo.c
M 58 [*70] ( 75) foo.c
% svn diff -r 58 -r 75 foo.c
What if we just skipped the middle number and user a letter code there?
For example, we could use N to indicate that a given file needed to be
patched to move from the current rev to the server rev.
% svn status foo.c
M 58 N ( 75) foo.c
The user would have one less number to keep track of and we still
get across the fact that rev 58 needs 1 or more patches to get to rev 75.
Having the server status code to the right of the first rev might provide
a better mapping since there is a natural pairing there.
(local-status revision) (server-status revision)
It might even help to make this pairing more obvious on the output line:
% svn status foo.c
M 58 (N 75) foo.c
A second status area also brings up the possibility of displaying other
useful values to indicate the file's current status on the server. For example,
the file might have been deleted on the server.
% svn status foo.c
M 58 (D 75) foo.c
Or perhaps the file had been renamed on the server.
% svn status foo.c
M 58 (R 75) foo.c
As far as the "don't contact the server" thing goes, I think contacting the
server should be the default. Passing a --update flag to the status command
seems very confusing. The () pairing might look like this if the server
could not be contacted.
% svn status foo.c
M 58 () foo.c
I am not really married to the () here, I just thought they would make
it easier to a human reader to visually parse the local status from the
server status. A regexp for either is trivial so that is not much of a concern.
cheers
Mo DeJong
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006