darcs --xml has the following limitations:

1) There is no way to get the list of files (--verbose seems ignored)

2) The dates (in <date>) are in a proprietary format. IMHO, they should be in
W3C Schema xsd:date or in ISO 8601 ("2005-11-30T10:03:06+0100") or RFC 3339 (a
subset of ISO 8601)

On Wed, Nov 30, 2005 at 09:06:11AM +0000, Bortzmeyer wrote:
> darcs --xml has the following limitations:

>From context, it's clear that you mean darcs changes --xml

> 1) There is no way to get the list of files (--verbose seems ignored)

You can get this with darcs annotate --xml.  Adding --summary or --verbose
would be doable, but I'm downgrading this to wishlist, since the
functionality is already there.

> 2) The dates (in <date>) are in a proprietary format. IMHO, they should
> be in W3C Schema xsd:date or in ISO 8601 ("2005-11-30T10:03:06+0100") or
> RFC 3339 (a subset of ISO 8601)

You just need to add some dashes, a T and some colons and a +000 to get ISO
8601.  I don't think I'd want to output ISO 8601 until we know how to parse
it, and that's waiting on someone who wants to write a parser for it.  (See
issue31).  In the meantime, here's a useful converter for our proprietary
date format:

perl -pe s/(....)(..)(..)(..)(..)(..)/$1-$2-$3T$4:$5:$6+0000/
-- 
David Roundy
http://www.darcs.net

Also, another limit is that "darcs changes --xml" does not add an "encoding" to
the XML declaration, so the XML flow is sometimes not well-formed.

For instance, I use ISO-8859-1 in my record messages and the XML document is wrong:

% xmllint --noout /tmp/blog.xml 
/tmp/blog.xml:15: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xE9 0x3C 0x2F 0x6E
        <name>RFC 3835 terminé</name>

But if I just add <?xml version="1.0" encoding="iso-8859-1"?> at the beginning,
xmllint is now happy. darcs changes should do it (an option to set the encoding,
may be?)

On Thu, Dec 01, 2005 at 08:48:00PM +0000, Bortzmeyer wrote:
> Also, another limit is that "darcs changes --xml" does not add an
> "encoding" to the XML declaration, so the XML flow is sometimes not
> well-formed.

The trouble is that darcs has no way of knowing the encoding of your
content...

> But if I just add <?xml version="1.0" encoding="iso-8859-1"?> at the
> beginning, xmllint is now happy. darcs changes should do it (an option to
> set the encoding, may be?)

Indeed, that would be the solution, we'd need additional (optional?) input
indicating the encoding.
-- 
David Roundy
http://www.darcs.net

On Fri, Dec 02, 2005 at 01:05:22PM +0000,
 David Roundy <bugs@darcs.net> wrote 
 a message of 25 lines which said:

...
> Indeed, that would be the solution, we'd need additional (optional?) input
> indicating the encoding.

The proper solution is probably to convert commit messages (short and
long) to UTF-8 before storing in the repository. At the commit time,
darcs know the encoding (through the locale) and can therefore convert
from/to.

This would allow the exchange of patches between people with different
encodings and would solve the XML problem for free. 

The only problem is that someone has to code it :-) And darcs has to
accept repositories with non-UTF8 characters since they already exist
and we cannot obliviate them.

On Sat, Dec 03, 2005 at 02:14:13PM +0000, Bortzmeyer wrote:
> > Indeed, that would be the solution, we'd need additional (optional?)
> > input indicating the encoding.
> 
> The proper solution is probably to convert commit messages (short and
> long) to UTF-8 before storing in the repository. At the commit time,
> darcs know the encoding (through the locale) and can therefore convert
> from/to.
> 
> This would allow the exchange of patches between people with different
> encodings and would solve the XML problem for free.

Indeed, that would probably be the best solution for commit messages.  But
for actual file contents, we'd still need some user input, since different
files may be in different encodings, and needn't actually match the current
locale (e.g. translations).
-- 
David Roundy
http://www.darcs.net

On Sat, Dec 03, 2005 at 02:34:04PM +0000,
 David Roundy <bugs@darcs.net> wrote 
 a message of 27 lines which said:

> Indeed, that would probably be the best solution for commit
> messages.

Yes, and since it is the only thing (with the file names, another
tricky problem) displayed by "darcs changes", it would solve this part
of issue 33.

> But for actual file contents, we'd still need some user input, since
> different files may be in different encodings,

Yes, but it is another matter (and a much more difficult issue than
issue33).

I happened to come across the same encoding issue in Mercurial
recently, and I found that it behaves the way I expect.  I have
included a transcript because it demonstrates how to test this.

Specifically, I am recording metadata from a UTF-8 system and then
looking to see what happens on an ASCII system and a Latin-1 system.

For the purposes of this transcript, "hg ci" corresponds to "darcs
record" and "hg log" corresponds to "darcs changes".

$ locale | grep LANG            # what encoding is in use?
LANG=en_AU.utf8
$ locale -a                     # what encodings are available?
C
POSIX
en_AU
en_AU.iso88591
en_AU.utf8
$ hg ci -m 'Naïve test.'        # make metadata with non-ASCII.
$ hg log                        # was it stripped out?  (No.)
2008-10-21  Trent W. Buck  <trentbuck@gmail.com>

	* x:
	Naïve test.
	[2a43ed65ee0e] [tip]

$ LANG=C hg log | grep test     # what happens to unencodable chars?
	Na?ve test.
$ LANG=en_AU.iso88591 hg log | grep test | # does reencoding work?
> iconv --from iso-8859-1       # convert it back so we can check
	Naïve test.

Regarding the problem of darcs changes --xml --verbose, from #xml on
irc.freenode.net:

12:47 <twb> Suppose I have a UTF-8 XML file.  Is there a way to legally have arbitrary byte vectors -- not necessarily valid UTF-8 -- within this?
12:48 <twb> Specifically I am wrapping arbitrary files (with heterogeneous, unknown encodings) in some XML metadata.
12:48 <[wito]> twb: base64 encode them
12:48 <twb> [wito]: is that my only option?
12:48 <[wito]> twb yap
12:48 <twb> [wito]: OK, thank you.

I just noticed that this is a sort of umbrella bug tracking potentially
lots of different issues (and not just the character encoding one)

So far we've got
- issue1872 : ISO8601 dates in XML
- issue1143 : character encodings
- list of files (fixed by darcs changes --xml --summary?)