At 11:04 AM 12/4/2001 -0800, Greg Stein wrote:
>I fully expect a "proper" client to walk over a server using WebDAV
>requests. At any point, the user could just go ahead and checkout from the
>current point.
Oh. Sorry, I guess I completely misunderstood the purpose of the client
library. I had thought it would be the library that a client would use to
access the svn server. I hadn't realized they would also need a webdav
library to access it. I had also thought that a design goal for the library
was that it abstracted the repository access layer for clients, whether it
be ra_local, ra_dav, ra_sql, or ra_some_new_protocol.
In that case, can I ask what the purpose is of the client library? What
principle differentiates between the functionality that goes into
libsvn_client and that which each client will have to implement on their
own through webdav? Whether CVS had it? Complexity of implementation in
webdav? Expected demand? Use by the command line client? Some other obvious
principle that I am completely missing?
>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?
Well, I'd think that providing access to all sorts of properties would be a
good feature to offer clients. You don't have to get specific about it,
though, you could let the client decide what to do with them, provided you
documented the live ones provided by the svn server. I'd also think that
providing the set of revisions where a file actually changed along with the
details of each of the commits would be an important thing for clients to
have access to, so that they could provide their own "log" implementations
rather than relying on the command line client.
I agree that there are probably dozens of additional features you'd want to
add eventually, but that could be post version 2.0 or 3.0 or 4.0, if you
like. Besides, I would think that discovering the contents of the
repository would be one of the most basic of functions, more basic than
merge. The only reason it isn't already there is historical, it seems to me.
I'm just a kibitzer, of course, and you've forgotten more about Subversion
than I will ever know. If you want to turn down volunteers offering to add
this kind of functionality, that's your call. I'm just trying to understand
how you differentiate between what is allowed and what is not.
---------------------------------------------------------------------
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