On 20 Sep 2001 17:06:33 -0500
kfogel@collab.net wrote:
> The first two columns are the familiar text-mods and prop-mods
> columns, which people are already accustomed to.
Just to play the devil's advocate here, why would an end user care
about having the file mod and prop mod displayed in different
fields? Say a user added executable perms or something, why
can't we just display M to indicate that the file has been
modified in some way? With the XML based diff idea that has
been thrown around, the user could run "svn diff file" and
look at the XML markers to find out exactly how to the file
was changed.
...
> b. The asterisk could be "m" vs "d" instead, to indicate a
> regular mod versus a deletion. Heck, it could also
> distinguish between text mods and prop mods. But is the
> extra complexity really worth it, when compared with the
> stark expressive power of a single naked asterisk? Nah.
> Let's go with simplicity. :-)
Why go for simplicity in the server status field but split the
text and prop fields up for the local status? That seems a bit inconsistent.
> 3. There is a "don't contact the repository" switch, call it
> `--no-repos' for now. The output either doesn't show the head
> revision at all, or shows it as a question mark. It also
> doesn't attempt to show what is out-of-date. I hope it's clear
> why this switch is separate from the -M switch -- it's because
> one might want to see local info about all entries while still
> not going over the network.
I was very much in the "contact by default" camp, but I have to
wonder if that is really the most common usage. I don't use
the CVS status command much because it sucks so badly so
I can't really speak from experience. I guess I would be happy
either way, as long as the flag to activate the repository is
not called --update.
Also, it seems like we are going to run into a big clash very
soon. There are only so many options we can use and
as far as I can tell the apr_getopt_long API does not
let you define a long option without associating a short
option. It also does not seem possible to have multiple
long options use the same short option number. For
example, -u could not be used for --update and --unidiff
in two different subcommands. Perhaps this is why CVS
parses the option before the subcommand differently
than the ones after.
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:42 2006