On 2006-1-10 Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 1/10/06, Bart Robinson <lomew@pobox.com> wrote:
>
> > I was thinking something like --explain/-x and the output would
> > be something like, instead of
> > M 965 wc/bars.c
> > * 965 wc/foo.c
> > A + 965 wc/qxxxx.c
> > this
> > wc/bars.c@965 (prop-mod)
> > wc/foo.c@965 (updatable)
> > wc/qxxxx.c@965 (added, w/hist)
>
> This is really far too amusing. I think we're living in mirror universes.
>
> Let me guess: are you a perforce user? Your suggested output format
> looks a *lot* like the output of 'p4 open'.
>
> The funny thing is, I was just complaining at work today about how
> much I hated p4's output, particularly how hard it was to read. p4
> puts the variable-length path as the first item in each line, thereby
> effectively destroying all column alignment, and making it really hard
> to parse. It doesn't use status codes, but full words to describe the
> edits. I was moaning and wondering why on earth p4 doesn't create
> nice neat little columns like 'svn status' does.
Oh no amigo, I'm not advocating perforce by any means. I've
been evaluating it lately, and frankly I can't stop vomiting.
To do a checkout I have to edit two or three files, choose a
non-conflicting name for my workspace, type some weird mapping
syntax (... has nothing to do with . or .., it is more like *,
but I guess *** was taken?), and remember to take out the Host:
field if, for some bizarre reason, I want to access my workspace
from a different machine. To type in my commit message I have
to first scroll down 23 lines of boilerplate text. If I want to
*script* these sort operations I have to save the form,
transform it somehow, and then feed it back to the command,
either in a pipeline or by managing tmpfiles, leaving turds
whenever I screw the args to "trap." To figure out what state
my workspace is in I can't just run one command, I have to run,
like, three and I'm probably forgetting one. Propagating one
change to another branch is easy enough, but backing out a
change is not symmetric so I'm sure to always have to go bug
that one guy who knows. Annotate only shows change numbers or
revisions, to get user/date info I have to do each manually,
write a script, or go into some other tool. I can't abbreviate
many commands, I have to type d e s c r i b e and f i l e l o g.
And the lack of a good bonsai like query tool or
thing-you-can-link-to that has good side-by-side diffs, links to
logs, etc, like viewvc, makes it a lot of work to integrate with
how my company uses bugzilla.
I'm not saying p4 it is total crap, it has some fine features,
but usability wise I find it below-target.
I agree its output style should not be emulated, like you say,
all that verbosity and long depot paths scrolling by just make
people ignore them. What I was getting at with the -x option
was to have a way to make svn's concise but arguably cryptic
status output a little easier to read for newbies. I have some
coworkers that are either uncomfortable with our current CVS (so
they aren't used to its similar output) or very comfortable with
perforce and I was thinking of some way to head off some of the
questions that will come from interpreting svn output. I
figured that since I was going to have to do *something* (write
a script, wrapper, docs, etc) I might as well check to see if
there were others that wanted it and just needed someone to
actually do it.
The problem I'm realizing is that I probably wouldn't even use
it myself, I'd just print out 'svn help stat and put it my my
desk until my eyes lose their virginity, so I'm not hell of
motivated to really make a case for it.
But I like bitching about perforce, so I'm glad you brought that
up :-).
-- bart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 11 10:18:26 2006