[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 333 - trunk/subversion/libsvn_ra_local trunk/subversion/clients/cmdline

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2001-10-30 00:10:30 CET

Greg Stein <gstein@lyra.org> writes:
> Why don't we make it fixed length? It isn't like we *need* it to be variable
> length.
>
> Further, why is the day, dst, and gmt_off in there? We don't need any of
> those for anything do we?

Not sure, would have to check the rest of the code first. Probably we
don't, though.

The point is that we have bidirectional conversion functions for
apr_time_t<-->string, and therefore don't want those strings to lose
information.

> 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."

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?).

-K

---------------------------------------------------------------------
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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.