[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: Johan Sundström <johsu650_at_student.liu.se>
Date: 2001-10-29 16:52:15 CET

> >...
> > + printf ("rev %lu: %s %s, %d bytes\n", rev, author, dbuf, strlen (msg));
> 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."

Okay, I agree I'm not your typical user, having maintained two generations
of a web cvs browser, but my reaction upon finding that size marker was a
warm-hearted cheer. One of those ever so many fuzzy feelings I got while
getting aquainted with subversion lately - my "Yes, they thought about
that aspect too!" mantra.

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

That is true, on the one condition that svn enforces a policy of
rejecting the "-----" separator in log messages. I seriously consider
a log format that is not both human-readable and machine parsable a
bad idea.

The nicest solution I have seen to date for this type of problem is
adding a leading space character to every line of the log message -
it can even make the log output more readable, to human and machine

Pretty please, let's be better than cvs?

(Not saying that a --parsable, --xml or similar flag wouldn't do the
trick too, but I got afraid of ending up with neither.)

/ Johan Sundström
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.