You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mattias Rönnblom <ho...@lysator.liu.se> on 2001/11/30 16:41:48 UTC
browsing the reprository
Hi,
I can't seem to find any way of traversing the reprository (stat(),
opendir() readdir()-like functionlity) in the RA layer. Isn't there
any?
I'm trying to implement
svn ls [-r] [URL|wc-path]
I'm not sure whether this is a useful feature or bloat, but it
looked like a nice way of getting to know SVN under to hood.
The use might be:
A developer has forgot the name of the branch that holds all the
fixes for the 1.0 release. He wishes to see a list of all the
branches, preferable without checking out the whole enshilada.
He may do
svn ls $URL/branches
Kind regards,
Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the reprository
Posted by Bruce Atherton <br...@callenish.com>.
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
Re: browsing the reprository
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 03, 2001 at 06:55:26PM -0500, Brandon Ehle wrote:
>...
> > You can perform a checkout from anywhere within the tree you are
> > browsing, even on a particular revision if you like.
> >
> > Because of the lack of an 'ls' in cvs, its clients never implemented
> > this.
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.
A GUI client could do this today, with no changes on our part.
>...
> > I'm not that particular about whether the command line client exposes
> > 'ls' functionality (although I don't see why not), but I think it
> > would be highly desirable to include this within the client library.
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.
And yes: I realize that pointing to DAV as the answer disregards ra_local.
But ra_local is the black sheep. Our intent is that ra_dav is the primary
mechanism (read: best supported) for talking to the server.
> > If you don't, then we end up with the same scenario of switching
> > between multiple tools just to perform a checkout.
>
> Yeah, I agree that this is a really bad limitation to CVS that even
> WebDAV doesn't entirely fix, that will *hopefully* get addressed.
Huh? WebDAV *does* entirely fix it. Please explain if you believe otherwise.
PROPFIND is used to navigate a repository. We do it today, and we always
would in the future. The advanced browsing that I mention above is solely
based on WebDAV's PROPFIND method.
Cheers,
-g
--
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
Re: browsing the reprository
Posted by Brandon Ehle <az...@yahoo.com>.
>
>
>> Mattias, this is probably unnecessary, since this 'browsing'
>> functionality is really part of the reason we're using the WebDAV
>> protocol.
>
>
> I hope you will reconsider this. The only reason an 'ls' was not put
> into CVS is because of the limitations the CVS development group put
> on commits. There are several patches that implement this floating
> around because so many people considered it useful. You could
> approximate the functionality by using "cvs -n co ." but it was
> entirely hackish.
>
> Because of this limitation, the cvs GUI clients were always inferior
> to many other versioning systems. Some have clients that provide
> access to the repository as a tree, with both directories and files
> expandable. The files expand to show you the revisions of the file (in
> svn, it would be just the revisions where a file changed, I guess).
> You can perform a checkout from anywhere within the tree you are
> browsing, even on a particular revision if you like.
>
> Because of the lack of an 'ls' in cvs, its clients never implemented
> this. Instead, they relied on developers just knowing the structure of
> the repository. Because any reasonably complex project is not easily
> memorizable, developers end up switching back and forth between their
> browser (pointing to Greg's excellent ViewCVS) and their cvs client.
>
> I'm not that particular about whether the command line client exposes
> 'ls' functionality (although I don't see why not), but I think it
> would be highly desirable to include this within the client library.
> If you don't, then we end up with the same scenario of switching
> between multiple tools just to perform a checkout.
Yeah, I agree that this is a really bad limitation to CVS that even
WebDAV doesn't entirely fix, that will *hopefully* get addressed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the reprository
Posted by Bruce Atherton <br...@callenish.com>.
At 11:06 AM 11/30/2001 -0600, 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 hope you will reconsider this. The only reason an 'ls' was not put into
CVS is because of the limitations the CVS development group put on commits.
There are several patches that implement this floating around because so
many people considered it useful. You could approximate the functionality
by using "cvs -n co ." but it was entirely hackish.
Because of this limitation, the cvs GUI clients were always inferior to
many other versioning systems. Some have clients that provide access to the
repository as a tree, with both directories and files expandable. The files
expand to show you the revisions of the file (in svn, it would be just the
revisions where a file changed, I guess). You can perform a checkout from
anywhere within the tree you are browsing, even on a particular revision if
you like.
Because of the lack of an 'ls' in cvs, its clients never implemented this.
Instead, they relied on developers just knowing the structure of the
repository. Because any reasonably complex project is not easily
memorizable, developers end up switching back and forth between their
browser (pointing to Greg's excellent ViewCVS) and their cvs client.
I'm not that particular about whether the command line client exposes 'ls'
functionality (although I don't see why not), but I think it would be
highly desirable to include this within the client library. If you don't,
then we end up with the same scenario of switching between multiple tools
just to perform a checkout.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the repository
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Hey everyone, did we ever reach a consensus on whether or not to
>include this `ls' functionality?
>
>For what it's worth, I'm +1. Although "svn ls" might seem like
>creeping featurism -- okay, *is* creeping featurism -- it's still
>something [almost] everyone wants to do. Making new svn_ra_plugin_t
>functions seems like the right way to go, although instead of exposing
>the node_rev concept, I'd rather see the functions take revs and paths
>like anything else (if the session wants to cache node information, it
>can).
>
>Anyway, implementation details aside, how did people feel about this?
>
+1
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the repository
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Anyway, implementation details aside, how did people feel about this?
>
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the repository
Posted by Daniel Stenberg <da...@haxx.se>.
On 7 Feb 2002, Karl Fogel wrote:
> Hey everyone, did we ever reach a consensus on whether or not to include
> this `ls' functionality?
...
> Anyway, implementation details aside, how did people feel about this?
+1
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the repository
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Hey everyone, did we ever reach a consensus on whether or not to
include this `ls' functionality?
For what it's worth, I'm +1. Although "svn ls" might seem like
creeping featurism -- okay, *is* creeping featurism -- it's still
something [almost] everyone wants to do. Making new svn_ra_plugin_t
functions seems like the right way to go, although instead of exposing
the node_rev concept, I'd rather see the functions take revs and paths
like anything else (if the session wants to cache node information, it
can).
Anyway, implementation details aside, how did people feel about this?
-Karl
Mattias Rönnblom <ho...@lysator.liu.se> writes:
> I've implemented a prototype of "svn ls". Now you can do stuff like:
>
> matro@isengard$~> mkdir svnrepos && svnadmin create ~/svnrepos
> matro@isengard$~> export REPOS=file:///home/matro/svnrepos
> matro@isengard$~> cd svn
> matro@isengard$~/svn> svn co $REPOS
> matro@isengard$~/svn> cd svnrepos/
> matro@isengard$~/svn/svnrepos> mkdir dir1 && svn add dir1
> A dir1
> matro@isengard$~/svn/svnrepos> touch dir1/file1 && svn add dir1/file1
> A dir1/file1
> matro@isengard$~/svn/svnrepos> svn commit
> Adding /home/matro/svn/svnrepos/dir1
> Adding /home/matro/svn/svnrepos/dir1/file1
> Commit succeeded.
> matro@isengard$~/svn/svnrepos> touch dir1/file2 && svn add dir1/file2
> A dir1/file2
> matro@isengard$~/svn/svnrepos> svn commit
> Adding /home/matro/svn/svnrepos/dir1/file2
> Commit succeeded.
> matro@isengard$~/svn/svnrepos> svn ls
> d dir1
> matro@isengard$~/svn/svnrepos> cd ..
> matro@isengard$~/svn> rm -rf svnrepos/
> matro@isengard$~/svn> svn ls $REPOS
> d dir1
> matro@isengard$~/svn> svn ls $REPOS/dir1
> f file1
> f file2
> matro@isengard$~/svn> svn ls -r 1 $REPOS/dir1
> f file1
> matro@isengard$~/svn>
>
> This currently only works with the ra_local RA access layer (besides
> wc). You probably want to change the ls output, and possibly add
> some "-v" or "-l" flag to have some more verbose informatino on each
> node.
>
> The only nontrivial task I've come across this far is designing
> the "reprository browsing" API. In my code, I've added a bunch of
> functions the the RA access plugin (svn_ra_plugin_t in svn_ra.h).
> You will use the get_node_rev to get a handle to a specific node
> revision in the reprository. Then you may access the different
> kinds of attributes, such as which kind of node it is, it's path,
> the directory entries (if it's a directory node revision) using
> this handle.
>
> svn_error_t *(*get_node_rev) (void *session_baton, void** node_rev_baton,
> svn_stringbuf_t* rel_path,
> svn_revnum_t revision);
>
> svn_error_t *(*get_node_rev_abs_path) (void *session_baton,
> void* node_rev_baton,
> svn_stringbuf_t** abs_path);
>
> svn_error_t *(*get_node_rev_rel_path) (void *session_baton,
> void* node_rev_baton,
> svn_stringbuf_t** rel_path);
>
> svn_error_t *(*get_node_rev_basename) (void *session_baton,
> void* node_rev_baton,
> svn_stringbuf_t** basename);
>
> svn_error_t *(*get_node_rev_kind) (void *session_baton, void* node_rev_baton,
> svn_node_kind_t* kind);
>
> svn_error_t *(*get_node_rev_dir_entries) (void *session_baton,
> void *node_rev_baton,
> apr_hash_t **node_revs);
>
> You probably want to add some functions to support traversal of
> not only the directory structure, but also the revision ancestry
> tree. But when implementing "ls", you don't need that.
>
> Should I clean up and submit my changes? If people think this might
> be useful, and something that should be included into Subversion,
> I might have a look at implementing this for ra_dav also.
>
> //Mattias
>
> ---------------------------------------------------------------------
> 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
Re: browsing the repository
Posted by Mattias Rönnblom <ho...@lysator.liu.se>.
Hi,
I've implemented a prototype of "svn ls". Now you can do stuff like:
matro@isengard$~> mkdir svnrepos && svnadmin create ~/svnrepos
matro@isengard$~> export REPOS=file:///home/matro/svnrepos
matro@isengard$~> cd svn
matro@isengard$~/svn> svn co $REPOS
matro@isengard$~/svn> cd svnrepos/
matro@isengard$~/svn/svnrepos> mkdir dir1 && svn add dir1
A dir1
matro@isengard$~/svn/svnrepos> touch dir1/file1 && svn add dir1/file1
A dir1/file1
matro@isengard$~/svn/svnrepos> svn commit
Adding /home/matro/svn/svnrepos/dir1
Adding /home/matro/svn/svnrepos/dir1/file1
Commit succeeded.
matro@isengard$~/svn/svnrepos> touch dir1/file2 && svn add dir1/file2
A dir1/file2
matro@isengard$~/svn/svnrepos> svn commit
Adding /home/matro/svn/svnrepos/dir1/file2
Commit succeeded.
matro@isengard$~/svn/svnrepos> svn ls
d dir1
matro@isengard$~/svn/svnrepos> cd ..
matro@isengard$~/svn> rm -rf svnrepos/
matro@isengard$~/svn> svn ls $REPOS
d dir1
matro@isengard$~/svn> svn ls $REPOS/dir1
f file1
f file2
matro@isengard$~/svn> svn ls -r 1 $REPOS/dir1
f file1
matro@isengard$~/svn>
This currently only works with the ra_local RA access layer (besides
wc). You probably want to change the ls output, and possibly add
some "-v" or "-l" flag to have some more verbose informatino on each
node.
The only nontrivial task I've come across this far is designing
the "reprository browsing" API. In my code, I've added a bunch of
functions the the RA access plugin (svn_ra_plugin_t in svn_ra.h).
You will use the get_node_rev to get a handle to a specific node
revision in the reprository. Then you may access the different
kinds of attributes, such as which kind of node it is, it's path,
the directory entries (if it's a directory node revision) using
this handle.
svn_error_t *(*get_node_rev) (void *session_baton, void** node_rev_baton,
svn_stringbuf_t* rel_path,
svn_revnum_t revision);
svn_error_t *(*get_node_rev_abs_path) (void *session_baton,
void* node_rev_baton,
svn_stringbuf_t** abs_path);
svn_error_t *(*get_node_rev_rel_path) (void *session_baton,
void* node_rev_baton,
svn_stringbuf_t** rel_path);
svn_error_t *(*get_node_rev_basename) (void *session_baton,
void* node_rev_baton,
svn_stringbuf_t** basename);
svn_error_t *(*get_node_rev_kind) (void *session_baton, void* node_rev_baton,
svn_node_kind_t* kind);
svn_error_t *(*get_node_rev_dir_entries) (void *session_baton,
void *node_rev_baton,
apr_hash_t **node_revs);
You probably want to add some functions to support traversal of
not only the directory structure, but also the revision ancestry
tree. But when implementing "ls", you don't need that.
Should I clean up and submit my changes? If people think this might
be useful, and something that should be included into Subversion,
I might have a look at implementing this for ra_dav also.
//Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the repository
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Barry Scott" <ba...@ntlworld.com> writes:
> 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.
Well, I'd rather we output stuff in the general style of parseable
format we've been using, and let those tools that want to parse it do
so (as opposed to svn having to know about N different formats).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: browsing the repository
Posted by Barry Scott <ba...@ntlworld.com>.
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 <gs...@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
Re: browsing the repository
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
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 <gs...@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
Re: browsing the repository
Posted by Greg Stein <gs...@lyra.org>.
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
Re: browsing the reprository
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> 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.)
I agree (should have participated more fully in this conversation when
Ben and Greg Stein were having it in the office here earlier).
We don't want to duplicate all the functionality of cadaver. However,
*overlapping* with some of that functionality is probably inevitable,
and not a bad thing.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: browsing the repository
Posted by Barry Scott <ba...@ntlworld.com>.
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.)
---------------------------------------------------------------------
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
Re: browsing the reprository
Posted by Greg Hudson <gh...@MIT.EDU>.
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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the reprository
Posted by Mattias Rönnblom <ho...@lysator.liu.se>.
Greg Stein <gs...@lyra.org> writes:
> On Fri, Nov 30, 2001 at 11:06:38AM -0600, 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.
>
> Right.
>
To me, as a user, it seems reasonable to include primitive browsing
functionality in the SVN command-line client. Even though there
might be other tools already doing that. And the svn ls fits nicely
together with svn cp, mv etc.
But the availability of other tools make the issue much less important,
I guess.
I will have a look at cadaver.
Kind regards,
Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: browsing the reprository
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Nov 30, 2001 at 11:06:38AM -0600, 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.
Right.
>...
> Similarly, you can see README in revision 5 like this:
>
> http://svn.collab.net/repos/svn/$svn/bc/5/trunk/README
That is a private URL, not part of the defined API. Specifically, that $svn
part can be changed. We should not be pointing people at those URIs because
they are subject to change, and they have some restrictions on usage with
could trip people up.
>...
> well-covered; maybe you can work on improving the behavior of the
> first two bullet points above, instead of implementing new client
> subcommands?
Working more smoothly with cadaver (and other DAV clients) is always a nice
thing.
Cheers,
-g
--
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
Re: browsing the reprository
Posted by Ben Collins-Sussman <su...@collab.net>.
Mattias Rönnblom <ho...@lysator.liu.se> writes:
> I'm trying to implement
>
> svn ls [-r] [URL|wc-path]
>
> I'm not sure whether this is a useful feature or bloat, but it
> looked like a nice way of getting to know SVN under to hood.
Mattias, this is probably unnecessary, since this 'browsing'
functionality is really part of the reason we're using the WebDAV
protocol.
* Go build a utility called 'cadaver'. Joe Orton wrote it, and it's
an ftp-like shell for browsing a webdav server. It works 95%
right now against a Subversion server; you can interactively
browse the latest revision this way.
* Open your web browser and type a normal URL, like this:
http://svn.collab.net/repos/svn/trunk/README
Poof, there's the README file in the head revision. All we need
to do is tweak mod_dav to produce a repsonse when browsing
directories, and we're done. Your web browser is all you need.
Similarly, you can see README in revision 5 like this:
http://svn.collab.net/repos/svn/$svn/bc/5/trunk/README
* If you have a local repository (ra_local), try running the
svnadmin tool like this:
$ svnadmin shell /path/to/local/repos
Now you can interactively explore different revisions, and examine
node-rev-ids for debugging purposes.
So, in summary: it's great that you want to contribute to
Subversion. But think the problem you're trying to solve is already
well-covered; maybe you can work on improving the behavior of the
first two bullet points above, instead of implementing new client
subcommands?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org