On Apr 10, 2008, at 16:03, John Peacock wrote:
> Filip Kolendo wrote:
>> $ svnlook lock /svn/repos tree.jpg
>> UUID Token: opaquelocktoken:ab00ddf0-6afb-0310-9cd0-dda813329753
>> Owner: harry
>> Created: 2005-07-08 17:27:36 -0500 (Fri, 08 Jul 2005)
>> Expires:
>> Comment (1 line):
>> Rework the uppermost branches on the bald cypress in the foreground.
>
> Like all/most svn output, that output is specifically designed to be
> machine readable:
>
> <keyword>:<SP>value<LF>
>
> There is even a hint on the one possibly multiline value (Comment).
>
> XML output is not necessary to make output trivial to parse (in
> fact, I find XML to be grossly inefficient for many situations, this
> one being a prime example).
I agree, XML usually more trouble than it's worth. One nice aspect,
however, is when dealing with non-ascii data. You don't have to die
horribly or fail mysteriously because of mangled or missing LOCALE.
You can represent the full unicode set in XML even if you are limited
to just putting 7-bit ascii on the wire.
This would nicely work around the problem Fillip Kolendo describes on
his other thread:
On Apr 10, 2008, at 17:27, Filip Kolendo wrote:
> Hello all,
>
> in the repository there are files (and directories) with Polish names.
> Eg. file name contains Polish character LATIN SMALL LETTER O WITH
> ACUTE, utf-8 hex c3 b3
>
> svn status
> K telefon?\195?\179w.txt
>
> I want to write a post-lock script in which I have to call svnlook
> for details.
> I don't know how I should code the non-ascii characters.
>
> I tried:
> svnlook lock REPOS_PATH telefonów.txt
>
> answer:
> svn: Safe data 'PROJECT\03_PLOT_PLAN\telefon' was followed by non-
> ASCII byte 243
> : unable to convert to/from UTF-8
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-10 19:08:56 CEST