mod_dav_svn enhancement idea

In my working on the Insurrection project, I happened to run into a few
items that may be reasonable to update/enhance/fix in the mod_dav_svn.

Note, I have not gone and "just done it" as (1) I have a family and,
more importantly, (2) I wanted to make sure that this is not unreasonable.

In the normal HTTP GET operations for the directories, the current mod_dav_svn
produces XML that looks very much like this:

        <?xml version="1.0"?>
        <?xml-stylesheet type="text/xsl" href="/insurrection.xsl"?>
        <!DOCTYPE svn [
          <!ELEMENT svn (index)>
          <!ATTLIST svn version CDATA #REQUIRED
                          href CDATA #REQUIRED>
          <!ELEMENT index (updir?, (file | dir)*)>
          <!ATTLIST index name CDATA #IMPLIED
                          path CDATA #IMPLIED
                          rev CDATA #IMPLIED>
          <!ELEMENT updir EMPTY>
          <!ELEMENT file (prop)*>
          <!ATTLIST file name CDATA #REQUIRED
                          href CDATA #REQUIRED>
          <!ELEMENT dir (prop)*>
          <!ATTLIST dir name CDATA #REQUIRED
                          href CDATA #REQUIRED>
          <!ELEMENT prop (#PCDATA)>
          <!ATTLIST prop name CDATA #REQUIRED>
        ]>
        <svn version="1.1.4 (r13838)"
             href="http://subversion.tigris.org/">
          <index rev="258" path="/">
            <file name=".svn_index" href=".svn_index"></file>
            <dir name="branches" href="branches/"></dir>
            <dir name="releases" href="releases/"></dir>
            <dir name="tags" href="tags/"></dir>
            <dir name="trunk" href="trunk/"></dir>
          </index>
        </svn>

The first thing that caused some consternation is the fact that the repository
name is not included. The XML DTD shows that it is optional but it would
be handy. There is even code in mod_dav_svn/repos.c to check for and include
the name from the dav_resource * that is passed into dav_svn_deliver() but
there never seems to be a name. Now, I have worked around this with some
mod_rewrite tricks in Apache, so it is not an issue, but it would be nice to have.

The second question is why not include the same information that "svn ls"
produces. Something on the order of:

        <?xml version="1.0"?>
        <?xml-stylesheet type="text/xsl" href="/insurrection.xsl"?>
        <!DOCTYPE svn [
          <!ELEMENT svn (index)>
          <!ATTLIST svn version CDATA #REQUIRED
                          href CDATA #REQUIRED>
          <!ELEMENT index (updir?, (file | dir)*)>
          <!ATTLIST index name CDATA #IMPLIED
                          path CDATA #IMPLIED
                          rev CDATA #IMPLIED>
          <!ELEMENT updir EMPTY>
          <!ELEMENT file EMPTY>
          <!ATTLIST file name CDATA #REQUIRED
                          author CDATA #REQUIRED
                          revision CDATA #REQUIRED
                          size CDATA #REQUIRED
                          href CDATA #REQUIRED>
          <!ELEMENT dir EMPTY>
          <!ATTLIST dir name CDATA #REQUIRED
                          author CDATA #REQUIRED
                          revision CDATA #REQUIRED
                          href CDATA #REQUIRED>
        ]>
        <svn version="$Id$" href="http://www.sinz.org/Michael.Sinz/Insurrection/">
          <index rev="258" path="/" name="Web">
            <file name=".svn_index" href=".svn_index"
                  author="mks" revision="93" size="3646"/>
            <dir name="branches" href="branches/" author="mks" revision="1"/>
            <dir name="releases" href="releases/" author="mks" revision="1"/>
            <dir name="tags" href="tags/" author="mks" revision="233"/>
            <dir name="trunk" href="trunk/" author="mks" revision="258"/>
          </index>
        </svn>

(The above is from some test code that I wrote as a wrapper to the svn ls and
not from the mod_dav_svn - yet - it has also been re-formatted to look reasonable
in this EMail.)

Note that I have removed the prop element as it has never actually happened.
(I see the comment about where it maybe would go but...)

The point being here, is to include data that is already easily available
and without much risk of dramatic bandwidth increase. (In fact, if that was a
worry, extra white space could be removed - after all, this is XML and most any
XML view will automatically produce the XML tree)

Would something like this be acceptable? Should I make some of the fields
optional? (Why or why not...)

Note that I have a perl hack that does just this after parsing the svn ls
output. This is not, by any means, the best choice of implementation but
it was mainly for proof of concept.

The advantages are that the data now contains more information that would
be useful for the display of the "directory" listing. (And not just in the
XML, the HTML could also be addressed.)

What do those of you who are deeper in the code think of the impact of
doing the extra svn_repos_get_committed_info() operations to the overall
system? My take on it is that it only impacts those who use the mod_dav_svn
to list/enumerate the repository and this is generally over the network.
The advantage is that there is no need to do multiple client-server interactions.
(Maybe the svn ls code could just grow XML output instead ;-)?

I need to do a lot more thinking about this, but before I charge down a path,
is this even a reasonable suggestion/idea? What are the plans for the prop
element and should it be removed? (It has not been generated, from what I can
see and has been optional.)

BTW - I really wish svn log --limit existed in the 1.1.x - it would really
be a life-saver for those larger repositories.

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org	
My place on the web                            http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org