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

Re: bad output format design issue: svn log -v format is not parseable :-(

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2004-04-05 18:50:10 CEST

On Apr 5, 2004, at 11:15 AM, C.A.T.Magic wrote:

> Marc Haisenko wrote:
>
>> On Monday 05 April 2004 14:54, kfogel@collab.net wrote:
>>> Saying this output is "not parseable" or "evil" is a bit strong :-).
>>>
>>> The output is, in a very rare edge case, ambiguous. If you create
>>> files whose names end in " (from ...)", you will have a problem, yes.
>>> Sorry for that -- perhaps we should have been better about escaping.
>>> Nevertheless, *do* you actually create such files? If not, the
>>> output
>>> is quite easy to parse.
>> But someone might do so sometime, and the universe likes to produce
>> people that do just these things from which other people think "this
>> won't happen, or happen rarily" ;-) It's always the same... and a
>> filename ".*(from.*)" is not all that unlikely.
>> In the normal command line output I can't think of an alternative as
>> this format also has the advantage of being easily parsed with a
>> regexp, although you can run into a bug if your regexp is not built
>> carefully enough. But in the XML output you could surely make this a
>> tag property pretty easily, no ?
>
> If you follow the thread I tried XML and ended with a new problem,
> the "#13\r\n" linefeeds inside of the log messages.

Ah, okay, had forgotten that. Those issues look surmountable.

You can see here what is prescribed for white-space and end-of-line
handling:
   http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space

You may find that you have a non-compliant processor. Compliant
processors
are readily available for C/C++/Java (see my comment below), but I
don't know
about Ruby/Python, etc.

> I also think using an XML parser for this task is overkill.
> I'd get a new deopendency on an XML parser module in my tools,
> have to find a free or at least LGPL parser that is bugfree and
> up-to-date etc...

Well, Subversion uses expat which is included with apr-util. It is
included in the source tarball and has a BSD-style license. For Java
and C/C++ apps, I've used Xerces (http://xml.apache.org ; again, a very
liberal license ). You may find that once you have such a reusable
software component, it proves its worth in numerous other applications.
  But then again, perhaps not for your tasks.

> maybe my simple "TAB" patch will do.

That it may.

-Travis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 18:54:08 2004

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.