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

Re: [PATCH] 'svn blame --xml' - v2

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-05-04 10:43:05 CEST

"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"?>

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

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.