> On Mon, Oct 29, 2001 at 05:10:30PM -0600, Karl Fogel wrote:
> > Greg Stein <gstein@lyra.org> writes:
> >...
> > > Users will be confused by that "103 bytes" in there. Bytes for what? The
> > > diff? It will take a bit before they realize "oh! the length of the log
> > > message."
> > >
> > > Users don't need that value. I don't think it is right to put it in there.
> > >
> > > And if you want to say "but we want a parsable output", then use XML. Or a
> > > flag or something. But don't burden *users* with stuff only intended for a
> > > program. Not to mention the program can figure it out for itself anyways
> > > just by scanning for the "-----" separator.
> >
> > No, that doesn't work.
> >
> > You might say, "C'mon, who would ever put the separator in their log
> > message itselfq?"
> >
> > To which I would say "Believe it or not, I have encountered that very
> > problem several times from users of cvs2cl.pl. No matter how small a
> > chance it is, there will always be *someone* out there who does it."
>
> I've seen it to, so I believe it. But a byte count for *user* output isn't
> the right solution.
>
> > So we cannot depend on the separator. The byte count is not so
> > confusing, really (I mean, were *you* confused, or are you just
> > assuming that other people might get confused?).
>
> Yes. I got confused. Maybe I'm an old fart who's going senile, but I saw "%d
> bytes" and went "wtf?". Then I saw the strlen(msg) and went "huh?!". And
> then finally it dawned on me the purpose of that field.
>
> I like the idea of indenting each line by one space, keeping the -----
> marker, and dropping the byte count.
>
> Or, creating a rich output format.
I'm +1 on this or something like this. Maybe a the --verbose option to
log could spit out something more easily parseable. Or we could
consider a --export-log function or something like that. I don't want
to get too far into creeping featuritis here, but I think that Karl is
speaking of a necessary feature.
-Fitz
---------------------------------------------------------------------
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:46 2006