You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Files <fi...@poetryunlimited.com> on 2003/11/07 03:44:56 UTC

The right library...to get info about a directory

Can someone enlighten me?

If I want to retrieve all the information on a directory in a repository, at
what level do I need to jack into the subversion library in order to avoid
repeated calls to svn info and svn log?

Barring that, is there a switch in the main svn program that I'm missing?

Verbose isn't doing it. It only spits out what the program thinks is verbose.
I get no log information. I get no properties. Just hints.

I realize that it's supposed to be human readable, but human beings can read a
lot more than blanks and single character hints.

Thanks.
-- 
Shamim Islam
BA BS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

In my previous post, I was attempting to suggest that --raw and --full might
be equivalent flags and that I don't care which is used. I should have used
the examples 'svn ls --raw' and 'svn ls --raw --xml'. Sorry. I mismatched the
alternative flag.
--
Shamim Islam
BA BS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by "C. Michael Pilato" <cm...@collab.net>.

"Files" <fi...@poetryunlimited.com> writes:

> I read the SWIG bindings, but I'm still not capable of leveraging it
> for PHP.  I can however, work in C. It would have been a lot simple
> for me to use the framework of svn itself.

Why not write a C wrapper for the functionality points that you need,
and then use SWIG *on your wrapper* to generate PHP bindings?  (For
the record, this is a rhetorical question asked to stir a thought
process within you -- I *do not want* a reply to this question).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

Ben Collins-Sussman said:
> On Wed, 2003-11-12 at 13:43, Files wrote:
>
> Please stop expecting the commandline client to do everything that the C
> library can do.  It's not going to happen.

I read the SWIG bindings, but I'm still not capable of leveraging it for PHP.
I can however, work in C. It would have been a lot simple for me to use the
framework of svn itself.

It's a lot more work to bring all that into an environment where no one else
is working on it, than to do it where it's mostly there, but ok.

> is really important to you, then please bring it up for discussion after
> 1.0.

K.
-- 
Shamim Islam
BA BS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Ben Collins-Sussman <su...@collab.net>.

On Wed, 2003-11-12 at 13:43, Files wrote:

> Ben said that the ra layer provides a list of directory structures on a
> get_dir (sorry if I'm spelling the function name wrong). However, the data
> inherent in them is not completely accessible.

It's not the commandline client's job to expose the complete innards of
every data structure it works with.  That's the whole reason Subversion
is written as a bunch of C libraries.  If you want data structure
innards, access them *programmatically*, not by parsing commandline
output.  You can use any language you want:  C, perl, python, java. 
Please stop expecting the commandline client to do everything that the C
library can do.  It's not going to happen.

> 'svn edit' would allow a remote editing session w/o requiring an intervening wc.

You're proposing a new feature that is pretty radical.  And this is the
absolute worst time to propose it:  we're trying to stabilize svn, avoid
adding new features at all costs in preparation for 1.0.  If the feature
is really important to you, then please bring it up for discussion after
1.0.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

Julian Foad said:
> A concrete, but tentative, proposal from me:
>
> + "svn list" (without "--verbose") should accept "--xml", and that should
> cause it to output, in XML format, for each directory entry:
>   + the item's name
>   + the item's type (file or directory)

Sorry Julian.

I keep misquoting myself.

Ben said that the ra layer provides a list of directory structures on a
get_dir (sorry if I'm spelling the function name wrong). However, the data
inherent in them is not completely accessible.

I had forgotten about the --verbose flag. Unfortunately --verbose is not
unequivocal in that it is still incomplete.

'svn ls --raw' would output all the directory structure information present in
human readable unambiguous format.
'svn ls --raw --xml' would output all the directory structure information in
xml format in unambiguous format.

Currently --verbose omits things it feels are unimportant and chooses to
format things 'nicely', instead of sticking to straight ascii representation
of the data - e.g. times not reported as a timestamp, etc. --raw would do so.

These are the things I am attempting to get at in a simplified way so, so that
I can go after the SWIG bindings when I am more comfortable w/ such.

'svn edit' would allow a remote editing session w/o requiring an intervening wc.
-- 
Shamim Islam
BA BS



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Julian Foad <ju...@btopenworld.com>.

Files wrote:
> Julian Foad said:
> 
>>>So how mad would everyone get if I added --full/--fullxml flags to ls?
>>
>>What do you propose these flags should do?  It might be better to enable XML
>>output (activated by the "--xml" switch) and ensure that the XML output is
>>"full".  Note that for "svn log", the XML output already has the full time
>>(not abbreviated).
> 
> I want 'svn ls --full' to dump raw directory contents in their entirety.

By "raw", I assume you mean "presented in some complete, unambiguous, machine-readable format".

I still do not know what you mean by "in their entirety".  What directory information is available that is not already printed by "svn list"?  If you mean that, for each item in the list, all the information that can be obtained about that item should be included (such as the log, the properties, etc.) then I disagree.  (And I am talking about a version of "list" that is designed for machine processing, such as an API or an XML output format; not the default text output of "svn list".)

I think that "list" should produce a list of the items in a directory (or perhaps only the specified items), giving for each entry only the information that is essential:

+ the item's name
+ the item's type (file or directory)

That is what "svn list" does without "--verbose".

With "--verbose", it adds the file size which is not primary data (it is a property of the file text), and the details of the last commit which is just a part of the file's history which can be obtained from "log".  I do not see those pieces of information as being strictly necessary in a "list" command, though they are handy for a human user to look at.  The file size cannot be obtained efficiently from any other command at present, and that may be sufficient justification for it being reported by "list" (in the proposed XML/API output).

If you want to find further details about one or more of the entries, such as details of the last commit, or previous commits, use "log" on that item.  If you want the item's text, use "cat"; if you want its properties, use "propget", etc.

If there is some piece of information that is not available, then we can consider making it available somehow.  You mentioned that there is some information that "svn info" can show for a local WC item, that would also make sense for a repository item, but I do not know exactly which piece of information that is.  The checksum of the file's text?

A concrete, but tentative, proposal from me:

+ "svn list" (without "--verbose") should accept "--xml", and that should cause it to output, in XML format, for each directory entry:
  + the item's name
  + the item's type (file or directory)

+ I don't mind whether "svn list --verbose --xml" will be accepted, but if it is, it should output the same information as "svn list --verbose" but in XML format, with complete, unambiguous data fields.

I don't know how far that would go towards helping you, nor am I offering to implement it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Non-recursive checkout is broken?

Posted by Philip Martin <ph...@codematters.co.uk>.

Julian Foad <ju...@btopenworld.com> writes:

> Philip Martin wrote:
>> Julian Foad <ju...@btopenworld.com> writes:
>>
>>>After a non-recursive checkout
>> Issue 695.
>
> Issue 695 is '"svn checkout --nonrecursive" should be sticky'.

"svn checkout --nonrecursive" is broken and should be fixed or removed.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Non-recursive checkout is broken?

Posted by Julian Foad <ju...@btopenworld.com>.

Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> 
>>After a non-recursive checkout
> 
> Issue 695.

Issue 695 is '"svn checkout --nonrecursive" should be sticky'.

My point is the opposite: that "svn checkout --nonrecursive" is so sticky that I can't unstick it and get any subdirectories to appear by any means.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Non-recursive checkout is broken?

Posted by Philip Martin <ph...@codematters.co.uk>.

Julian Foad <ju...@btopenworld.com> writes:

> After a non-recursive checkout

Issue 695.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Non-recursive checkout is broken?

Posted by Julian Foad <ju...@btopenworld.com>.

After a non-recursive checkout (which gets all of the files but none of the subdirectories) I have not managed to get a subdirectory from the repository into my WC. I tried "svn update subdir" and "svn copy URL subdir" and "svn checkout URL subdir". The test script is attached, and the output, starting from after the checkout, is shown below.

I would expect that "status -vu" would show that the subdirectory would be added by an update, either by marking the parent entry (".") with an asterisk or by showing a status entry for "subdir" with an asterisk.

+ svn list -vR
1 julianfo 6 Nov 15 15:54 file
1 julianfo Nov 15 15:54 subdir/
1 julianfo 6 Nov 15 15:54 subdir/file
+ svn status -vu
1 1 julianfoad .
1 1 julianfoad file
Status against revision: 1

+ svn update subdir
svn: warning: svn_wc_is_wc_root: 'subdir' is not a versioned resource

+ svn copy file:///home/julianfoad/tmp/incomplete-wc/repos/subdir .
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:165: (apr_err=155004)
svn: Attempted to lock an already-locked dir
svn: working copy locked: .
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

+ svn checkout file:///home/julianfoad/tmp/incomplete-wc/repos/subdir
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:600: (apr_err=155005)
svn: Working copy not locked
svn: directory 'subdir' not locked

Each of "copy" and "checkout" creates a directory "subdir" and "subdir/.svn", but does not integrate it into its parent or populate it. The WC is not reported as Locked before or after these attempts.

I am not saying that all three of these methods should be valid ways to get the subdirectory, but I think at least "copy" and/or "update" should be. Perhaps I'm not trying the right way?

- Julian

Re: Working with incomplete WC, or no WC [was: Re: Abolish instant-commit commands]

Posted by Greg Hudson <gh...@MIT.EDU>.

On Sat, 2003-11-15 at 11:06, Julian Foad wrote:
> My point is that if the action that you want to perform is not a
> single copy or propset or mkdir, but a combination of any two or more
> of those (e.g. you want to set a custom property on your branch) then
> the instant-commit syntax cannot do it in one commit.  We ought to
> consider providing some mechanism for building up a multi-part
> transaction without a working copy - or at least without a complete
> working copy.

Ah, yes.  See
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=188086
for an example proposal involving long-lived transactions.

One could, alternatively, do all the work on the client.  "svn cp" could
have an option, perhaps just -N, to avoid populating the area being
copied to, or we could have a thing for queuing up operations
client-side without reflecting them in a working copy, and committing
them all at once.  Big design space here.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Working with incomplete WC, or no WC [was: Re: Abolish instant-commit commands]

Posted by Ben Collins-Sussman <su...@collab.net>.

On Sat, 2003-11-15 at 10:06, Julian Foad wrote:

> We ought to consider providing some mechanism for building up a
> multi-part transaction without a working copy - or at least without a
> complete working copy.

Ha, welcome to DeltaV.  It has a whole model for server-side working
copies, we just happen to ignore it right now.  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Working with incomplete WC, or no WC [was: Re: Abolish instant-commit commands]

Posted by Julian Foad <ju...@btopenworld.com>.

Branko Čibej wrote:
> Julian Foad wrote:
> 
>>For instance, there is an argument that "svn mkdir URL" is useful to
>>make a branch directory.  Of course it is, in the limited circumstance
>>of not wanting any properties set on that new directory.  As soon as
>>you go beyond the simple, the idea falls apart.
> 
> Uh. Compare this:
> 
>     svn cp http://svn.collab.net/repos/svn/trrunk \
>            http://svn.collab.net/repos/svn/branches/issue-xxx-dev
> 
> and this:
> 
>     svn co http://svn.collab.net/repos/svn
>     cd svn
>     svn cp trunk branches/issue-xxx-dev
>     svn ci

... your point being, presumably, that the second version requires so much data transfer as to make it impractical, and a bit more typing too.

OK, I was being over-dramatic when I suggested "abolishing" the existing instant-commit commands.  I concede that it is necessary to have a way to do operations like this directly on the repository and, for the time being, those commands are the means to do it.

My point is that if the action that you want to perform is not a single copy or propset or mkdir, but a combination of any two or more of those (e.g. you want to set a custom property on your branch) then the instant-commit syntax cannot do it in one commit.  We ought to consider providing some mechanism for building up a multi-part transaction without a working copy - or at least without a complete working copy.

"svn checkout --non-recursive" is probably the way to go, but I am not sure to what extent Subversion can cope with an incomplete working copy through a full cycle of checkout+modify+commit.  I got stuck at the first hurdle: after a non-recursive checkout (which gets all of the files but none of the subdirectories) I have not managed to get a subdirectory.  I tried "svn update subdir" and "svn copy URL subdir" and "svn checkout URL subdir".  The test script is attached, and the output from these attempts is shown below.

+ svn list -vR
      1 julianfo          6 Nov 15 15:54 file
      1 julianfo            Nov 15 15:54 subdir/
      1 julianfo          6 Nov 15 15:54 subdir/file
+ svn status -vu
                1        1 julianfoad   .
                1        1 julianfoad   file
Status against revision:      1

+ svn update subdir
svn: warning: svn_wc_is_wc_root: 'subdir' is not a versioned resource

+ svn copy file:///home/julianfoad/tmp/incomplete-wc/repos/subdir .
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:165: (apr_err=155004)
svn: Attempted to lock an already-locked dir
svn: working copy locked: .
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

+ svn checkout file:///home/julianfoad/tmp/incomplete-wc/repos/subdir
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:600: (apr_err=155005)
svn: Working copy not locked
svn: directory 'subdir' not locked

Each of "copy" and "checkout" creates a directory "subdir" and "subdir/.svn", but does not integrate it into its parent or populate it.  The WC is not reported as Locked before or after these attempts.

Perhaps this is possible but I'm not trying the right way?

- Julian

Re: Abolish instant-commit commands [was: Re: The right library...to get info about a directory]

Posted by Branko Čibej <br...@xbc.nu>.

Julian Foad wrote:

> For instance, there is an argument that "svn mkdir URL" is useful to
> make a branch directory.  Of course it is, in the limited circumstance
> of not wanting any properties set on that new directory.  As soon as
> you go beyond the simple, the idea falls apart.

Uh. Compare this:

    svn cp http://svn.collab.net/repos/svn/trrunk \
           http://svn.collab.net/repos/svn/branches/issue-xxx-dev


and this:

    svn co http://svn.collab.net/repos/svn
    cd svn
    svn cp trunk branches/issue-xxx-dev
    svn ci


-- 
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: Abolish instant-commit commands [was: Re: The right library...toget info about a directory]

Posted by Julian Foad <ju...@btopenworld.com>.

Files wrote:
> I understand what you're saying. I do see your point of view.
> 
> I'll take any suggestions you have for remote repository file maintenance.
> 
> E.g. webdav et al.
> 
> My repository browser allows regular filesystems and a subversion repository
> to appear seamlessly interconnected. I am wondering how I should proceed to
> allow users to to edit the contents of said repository via the same web
> interface that they would regular files.

If you want a system in which every individual change causes a commit, then you should hook into the Subversion libraries directly.  The Subversion command-line client is not designed to operate in this mode, even though it has some commands that can make an instant commit.

> Which in essence is how webdav works, if I'm not mistaken.

I don't know anything about WebDAV except that Subversion uses a subset of its protocol.

> If the repository exists on the local box, I can use wc. But my repository
> browser allows for:
> 
> http://www.svnexplorer.somesite.com/http/svn.someothersite.com/repos/myfiles
> 
> How should I handle that using the existing subversion framework without the
> instant commits?

I don't know.  Maybe make a temporary local working copy?

> I'll follow any lead you can give me.

I can help with some of the questions that directly affect the Subversion project, but cannot give you much help in designing your browser.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Abolish instant-commit commands [was: Re: The right library...toget info about a directory]

Posted by Files <fi...@poetryunlimited.com>.

I understand what you're saying. I do see your point of view.

I'll take any suggestions you have for remote repository file maintenance.

E.g. webdav et al.

My repository browser allows regular filesystems and a subversion repository
to appear seamlessly interconnected. I am wondering how I should proceed to
allow users to to edit the contents of said repository via the same web
interface that they would regular files.

Which in essence is how webdav works, if I'm not mistaken.

If the repository exists on the local box, I can use wc. But my repository
browser allows for:

http://www.svnexplorer.somesite.com/http/svn.someothersite.com/repos/myfiles

How should I handle that using the existing subversion framework without the
instant commits?

I'll follow any lead you can give me.
-- 
Shamim Islam
BA BS



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Abolish instant-commit commands [was: Re: The right library...to get info about a directory]

Posted by Julian Foad <ju...@btopenworld.com>.

Files wrote:
> 
> I'd also, really like to be able to do 'svn edit
> http://myrepos.com/repos/svn/testfile.txt --message "mymessage" -F myfile.txt'
> or 'svn edit http://myrepos.com/repos/svn/testfile.txt --message "mymessage" <
> myfile.txt'.

What would you like those commands to do?  I assume you would want them to make a commit which modifies "testfile.txt" to contain the text from "myfile.txt", but what properties?  No properties?  The properties from "testfile.txt@HEAD"?  The properties from some other, optionally specified revision?  And if you wanted to change the properties as well, would you use "propset" (or "propedit") to make a separate commit?  Or would you want a way of changing the properties in the same commit?  If you want to change more than one file, are you happy to use a separate commit for each file that you change in this way?

I don't like it at all.  Perhaps the precedent for your proposal is the existence of commands like "propset NAME VALUE URL..." and "mkdir URL" which cause an instant commit.  I would go the opposite way, and vote to abolish such instant commits.  Those commands are useful in some limited circumstances, and your proposal IS a logical extension of them, but they all head away from Subversion's basis of "one commit per logical change".

For instance, there is an argument that "svn mkdir URL" is useful to make a branch directory.  Of course it is, in the limited circumstance of not wanting any properties set on that new directory.  As soon as you go beyond the simple, the idea falls apart.

Even "import" is, in my view, a bad idea.  Normally one finds that one wants properties set or unset on files that are being imported, or wants to remove certain files from the import.  The ideal way to do this would be to "svn add" (in place or to another local directory which would become the WC), and then have the opportunity to modify properties, remove files, etc., before making the initial commit.  I know that "import" is "expected" by CVS converts, but I would prefer an "import to WC" which is the opposite of "export from WC".

Thoughts on reducing the set of "instant commit" commands to the bare essentials?

Thoughts on "import to WC"?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

Julian Foad said:
>> So how mad would everyone get if I added --full/--fullxml flags to ls?
>
> What do you propose these flags should do?  It might be better to enable XML
> output (activated by the "--xml" switch) and ensure that the XML output is
> "full".  Note that for "svn log", the XML output already has the full time
> (not abbreviated).

I want 'svn ls --full' to dump raw directory contents in their entirety.
Taking your suggestion, the 'svn ls --xml --full' would do a raw dump in xml
format. Or perhaps 'svn ls --raw'.

I'd also, really like to be able to do 'svn edit
http://myrepos.com/repos/svn/testfile.txt --message "mymessage" -F myfile.txt'
or 'svn edit http://myrepos.com/repos/svn/testfile.txt --message "mymessage" <
myfile.txt'.

I'm not sure if SWIG is the right first place to go for me. Especially since a
I've seen addons in perl and java seem to be replicating this sort of
behavior. I feel like I'm reinventing the wheel. Maybe the behavior should
just exist?

Can I do this? Am I the only person that sees value in something like this?

Or is this totally outside of what subversion is/should be able to do from the
command line.

Thanks in advance for any suggestions/guidance.
-- 
Shamim Islam
BA BS



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Julian Foad <ju...@btopenworld.com>.

[Moving from "users" to "dev" list.]

Files wrote:
> So how mad would everyone get if I added --full/--fullxml flags to ls?

What do you propose these flags should do?  It might be better to enable XML output (activated by the "--xml" switch) and ensure that the XML output is "full".  Note that for "svn log", the XML output already has the full time (not abbreviated).

> don't know if I could successfully subvert --xml when --full was supplied as a
> parameter.)
> 
> That would solve everything and actually emulate the unix ls (--fulltime option).

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

So how mad would everyone get if I added --full/--fullxml flags to ls? (I
don't know if I could successfully subvert --xml when --full was supplied as a
parameter.)

That would solve everything and actually emulate the unix ls (--fulltime option).

Just thinking out loud. Keep thinking - hooking into PHP right now seems much
more daunting than evolving svn.
-- 
Shamim Islam
BA BS

Ben Collins-Sussman said:
> On Sat, 2003-11-08 at 21:05, kfogel@collab.net wrote:
>
>> Yup, I understand now, thanks.
>>
>> Hmmm, I'm not sure we provide the right sorts of interfaces yet,
>> though.  We provide a lot of what you want in
>> svn_ra.h:ra_plugin_t:get_dir(), but not everything...
>
> And svn_client_list() is basically nothing more than a wrapper around
> RA->get_dir().   Both functions return you a list of repository dirent
> structures.  But at least svn_client_list() will automatically choose
> the correct RA layer based on the URL schema.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Ben Collins-Sussman <su...@collab.net>.

On Sat, 2003-11-08 at 21:05, kfogel@collab.net wrote:

> Yup, I understand now, thanks.
> 
> Hmmm, I'm not sure we provide the right sorts of interfaces yet,
> though.  We provide a lot of what you want in
> svn_ra.h:ra_plugin_t:get_dir(), but not everything...

And svn_client_list() is basically nothing more than a wrapper around
RA->get_dir().   Both functions return you a list of repository dirent
structures.  But at least svn_client_list() will automatically choose
the correct RA layer based on the URL schema.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by kf...@collab.net.

"Files" <fi...@poetryunlimited.com> writes:
> I'm creating a repostory browser.
> 
> I need access to all that information for a repository even when
> it's not local.
> 
> The local one's are not that hard to get information on.
> 
> But I want to be able to pull the data and present it in a customized
> navigable format.
> 
> Does that help?

Yup, I understand now, thanks.

Hmmm, I'm not sure we provide the right sorts of interfaces yet,
though.  We provide a lot of what you want in
svn_ra.h:ra_plugin_t:get_dir(), but not everything...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

Karl,

I'm creating a repostory browser.

I need access to all that information for a repository even when it's not local.

The local one's are not that hard to get information on.

But I want to be able to pull the data and present it in a customized
navigable format.

Does that help?
-- 
Shamim Islam
BA BS

kfogel@collab.net said:
> "Files" <fi...@poetryunlimited.com> writes:
>> Can someone enlighten me?
>>
>> If I want to retrieve all the information on a directory in a repository, at
>> what level do I need to jack into the subversion library in order to avoid
>> repeated calls to svn info and svn log?
>>
>> Barring that, is there a switch in the main svn program that I'm missing?
>>
>> Verbose isn't doing it. It only spits out what the program thinks is
>> verbose.
>> I get no log information. I get no properties. Just hints.
>
> So you want:
>
>    - entries
>    - properties on the directory itself
>    - properties on its entries?
>    - logs (but for which revisions?)
>    - history of when it was copied, if at all?
>    - ?
>
> Guess I'm not sure exactly what you're trying to do.  Can you be more
> specific?
>
> By the way, this might be more a question for the users list, I've
> CC'd there instead of dev.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by kf...@collab.net.

"Files" <fi...@poetryunlimited.com> writes:
> Can someone enlighten me?
> 
> If I want to retrieve all the information on a directory in a repository, at
> what level do I need to jack into the subversion library in order to avoid
> repeated calls to svn info and svn log?
> 
> Barring that, is there a switch in the main svn program that I'm missing?
> 
> Verbose isn't doing it. It only spits out what the program thinks is verbose.
> I get no log information. I get no properties. Just hints.

So you want:

   - entries
   - properties on the directory itself
   - properties on its entries?
   - logs (but for which revisions?)
   - history of when it was copied, if at all?
   - ?

Guess I'm not sure exactly what you're trying to do.  Can you be more
specific?

By the way, this might be more a question for the users list, I've
CC'd there instead of dev.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by John Szakmeister <jo...@szakmeister.net>.

Very intriguing. :-)

It sounds like you want to use something other than the command line tools to 
do this (and looking at the rest of this thread, others have suggested the 
same).

You should really look at using the bindings to get what you want done.  
They're pretty easy to use, and you'll get the information you seek with a 
lot less pain. :-)  Besides, the command line client has changed it's output 
in various ways several times, and depending on the output being formatted a 
particular way might not be the best of ideas. :-)

-John



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: The right library...to get info about a directory

Posted by Files <fi...@poetryunlimited.com>.

I am creating a repository browser. One that can walk the entire tree, just
like the filesystem that it emulates. To boot, it transitions into the
repository across the regular filesystem boundary as if it were nothing.

In addition, this browser is supposed to be able to retrieve any and all
information about the repository and it's contents and manipulate the same.

It's not viewcvs. Personally, that interface is too limiting for what I want
to accomplish.

The only issue I seem to be having is that I have no native language hooks
from PHP to do the tricks that viewcvs seems to be, so it seems that I will
have to invent the same.

So I'm looking for direction on how to get there.

I'm sending you a picture of the current results as a private email. I will do
the same for anyone else that wants to see it, but I'd rather not overload the
list.
-- 
Shamim Islam
BA BS

John Szakmeister said:
> On Thursday 06 November 2003 22:44, Files wrote:
>> Can someone enlighten me?
>>
>> If I want to retrieve all the information on a directory in a repository,
>> at what level do I need to jack into the subversion library in order to
>> avoid repeated calls to svn info and svn log?
>
> What information is it that you seek?
>
>> Barring that, is there a switch in the main svn program that I'm missing?
>
> Perhaps, but you need to say what you want here.
>
>> Verbose isn't doing it. It only spits out what the program thinks is
>> verbose. I get no log information. I get no properties. Just hints.
>
> What are you running?  'svn ls'?  'svn ls' is about reading directory
> contents.  If you want properties then you need to do 'svn pl' on the object
> you want properties on.
>
> I'm a bit confused by what your asking, and what it is your doing.  If you can
> explain what you are doing now, then maybe we can point you in the right
> direction to get the information that you seek, and hopefully in a format
> that you like. :-)
>
>> I realize that it's supposed to be human readable, but human beings can
>> read a lot more than blanks and single character hints.
>
> True, but in the same regard, we humans appreciate the limited availability of
> screen space (especially developers!), and appreciate the fact that we don't
> use a sentence where a character does the trick.
>
>> Thanks.
>
> -John
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org