You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@ntlworld.com> on 2001/12/01 21:00:38 UTC
RE: browsing the repository
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 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