"Peter N. Lundblad" <peter@famlundblad.se> writes:
> On Wed, 4 May 2005, [utf-8] Ã^Xyvind A. Holm wrote:
>
> > On 2005-05-04 08:24:09 Peter N. Lundblad wrote:
> > > On Wed, 4 May 2005, [utf-8] ?^Xyvind A. Holm wrote:
> > > > On 2005-05-02 05:09:09 alexander@collab.net wrote:
> > > > > Version: 2, Patch to add XML output for 'svn blame'
> > > > [...]
> > > > - And the actual text line with it's own element from the file is
> > > > missing in the XML.
> > >
> > > That's deliberate (see the feedback to the first version of the
> > > patch). In short, we don't know the encodig of the file content, so we
> > > can't include it in XML (which has to be UTF8, or some or some other
> > > encoding, but it has to be consistent.) It is easy to get at the
> > > content with svn cat.
> >
> > Yes, that's a good reason not to include the actual line text. But what
> > about including the actual line number instead? XML suggestion:
> >
> With an entry element for each line, I don't see a point in showing that
> the computer can count:-) Remember that this isn't for humans.
Isn't it kinda naughty to assume that order matters in XML output? I
mean, a text process should be able to reorder the <entry> subtrees
with no detriment to an XML parser.
Secondly, if we aren't showing the line data, is it desirable to have
entries cover more than one line of data at a time? Line ranges, that
is, like so:
<?xml version="1.0" encoding="utf-8"?>
<blame>
<target
path=".bashrc">
<entry
revision="32">
<author>sunny</author>
<date>1999-07-02T16:36:59.000000Z</date>
<startline>1</startline>
<endline>54</endline>
</entry>
Finally, where is the line drawn on what pieces of data are
represented at tag CDATA versus attribute values? I always assumed
that one of two trains of extremist thought might be prevalent:
- Never use attributes, period, or
- Use attributes for all data that doesn't have heirachy (which,
for our current 'svn blame' output, includes revision, author,
date, and pretty much every other thing in the <entry>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 4 10:44:40 2005