Karl,
I agree with your analysis.
I've looked into WebDAV and under stand where you are coming from
Greg. But I hate the idea of needing to use half the functions
from svn and the rest from some WebDAV library in my apps.
One suggestion for (2) taken from perforce p4 tool.
You can tell it to out the information from any command as a marshaled
python data structure. It would be nice to see svn have this ability.
Now I can say that I want the output of the svn ls --python command to
return a list of dictionaries detailing the elements at this location.
BArry
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 06 December 2001 09:01
> To: Greg Stein
> Cc: Barry Scott; dev@subversion.tigris.org
> Subject: Re: browsing the repository
>
>
> Sure, WebDAV a "primary access mechanism" for SVN repositories, but
> calling it that doesn't help users much. What concerns users is the
> functionality attainable from the client, and if `ls' is missing,
> that's a problem.
>
> For the record, I think it's *great* that anything that speaks DAV can
> speak to an SVN repository, and agree with Greg's assessment that
> ra_local is not of great importance to most users (though it's still
> mighty handy and won't be going away). But all that is beside the
> point; the really important questions here are:
>
> 1. Should the Subversion client provide repository browsing
> (i.e., `ls') capability, and
>
> 2. If so, how should it do it?
>
> As far as (1) is concerned, yes, we need to do it. I think it's
> *very* important that our client support that -- it's what people
> need. Can't remember that tag name? Well, you should be able to find
> it without checking out whole directories. :-) Can't remember where a
> particular file is? Well, you should be able to find it without
> checking out whole directories. :-)
>
> We have to ship with `ls', IMHO.
>
> In that case, let's ask question (2): how should our client do this?
> Well, the RA layer needs to provide sufficient functionality for
> libsvn_client to implement `ls'. It's that simple. We've taken great
> pains to keep the client independent from the details of the access
> protocol (local, network, or otherwise) up till now, and it's a good
> policy.
>
> Greg, you're worried that we'd head down a slippery slope:
>
> > Possibly. The real question becomes, "if we implement a function to do this,
> > will it handle all the needs?" I think that we'd end up just adding more and
> > more and more to the function (or growing it to a set of functions!) to deal
> > with increasingly sophisticated clients.
> >
> > For example, what about the last revision a file was modified in? What about
> > the binary, mime-type, and executable properties for a file? Modification
> > time? By whom?
> >
> > All of these are easily expressible if the client just used WebDAV and
> > fetched the interesting properties. We'd have a lot of covers to write if we
> > wanted to supply these to a client. And note it is only for browsing a
> > repository, not actual operation of the server.
>
> If we think a subversion client should do X, then we need to make sure
> the RA layer is rich enough to support X. This is not terribly
> difficult -- as you sort of imply above, a lot of these RA functions
> are just going to be wrappers around fairly simple WebDAV propfinds.
> So what? Big deal. Wrappers. Nothing wrong with 'em; they help keep
> things modular.
>
> We can't avoid having overlapping functionality with lots of existing
> (and future) WebDAV clients -- we're talking to a DAV server, after
> all. But overlap (even call it "duplication" if you want) is no sin
> if it provides the users what they need while keeping the software
> modular and maintainable.
>
> Let's do `ls', and let's do it the way we've done everything else.
>
> -Karl
>
> Greg Stein <gstein@lyra.org> writes:
> > ra_dav and WebDAV is the primary access mechanism for an SVN repository. A
> > high-level SCM app could use DAV methods against the server, and calls into
> > the SVN libraries when needed.
> >
> > Second question, of course, is how complete our DAV implementation? For 1.0,
> > we'll make it "complete enough [for the SVN client to talk to the server]"
> > plus any low-hanging fruit for interoperability. SVN 2.0 will provide full
> > WebDAV/DeltaV interop.
> >
> > Cheers,
> > -g
> >
> > On Sat, Dec 01, 2001 at 09:00:38PM -0000, Barry Scott wrote:
> > > How do you see a High-level SCM App that builds on svn solving the problem
> > > of browsing the repository to perform complex operations?
> > >
> > > BArry
> > >
> > > -----Original Message-----
> > > From: Greg Hudson [mailto:ghudson@MIT.EDU]
> > > Sent: 30 November 2001 23:58
> > > To: Ben Collins-Sussman
> > > Cc: dev@subversion.tigris.org
> > > Subject: Re: browsing the reprository
> > >
> > >
> > > On Fri, 2001-11-30 at 12:06, Ben Collins-Sussman wrote:
> > > > Mattias, this is probably unnecessary, since this 'browsing'
> > > > functionality is really part of the reason we're using the WebDAV
> > > > protocol.
> > >
> > > I disagree, because people may use ra_local or other access methods
> > > instead of WebDAV, and because I don't think basic functionality should
> > > be delegated to tools other than "svn".
> > >
> > > (I'm not saying that everything you can do through WebDAV should be
> > > reimplemented in svn, just that "ls" is basic enough to be in the
> > > category of things which should. And I'm not saying that "svn ls"
> > > should be a 1.0 requirement--mainly since CVS doesn't have it--but I
> > > think it should be an admissable feature.)
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:51 2006