[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: browsing the repository

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-08 01:15:40 CET

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 <hofors@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_at_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
Received on Sat Oct 21 14:37:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.