svn_ra_stat() does return the filesize, and it's the API that 'svn info'
uses. The next/prev links in the chain are svn_client_info3() and
ra_svn_stat() (the latter is a file-private function in libsvn_ra_svn).
So, yes, you're on the right path. However, I knew all these APIs would
exist, so I'm still where I was before: I'd like to know why the
proposed new feature is generally useful enough to be included in the
core, where it stands wrt 'svn log' and 'svn info', and how it would be
implemented.
In particular, implementing a protocol change involves a non-negligible
amount of work (to revv four transports, client and server, plus compat
code for old servers), while if it doesn't involve a protocol change the
question is "Why is a bindings script not a sufficient solution?".
Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 21:33:11 +0000:
> Hi all,
>
> I found the following when examining the svnlook code
> svn_fs_file_length where svn look gets the filesize. This is obviously the fs side function.
>
> In /libsvn_ra_svn/protocol
> I found the commands "stat" and "log"
>
> "stat" contains a response token of size:number
> "log" does not contain such a token
>
> I then had a search for svn_ra functions in various header files. But I could not locate an ra api counterpart for svn_fs_file_length.
>
> I cannot see if svn_ra_stat is providing filesize info, whilst being defined in /libsvn_ra_svn/protocol. (I hope I am interpreting this correctly) I neither can see if the server_side part encodes filesize information into the stream. Can somebody tell me where the answer is put into the stream?
>
>
> Am I on the right path? Is this already subject to the Dev Mailinglist? This is my starting point of subversion coding.
>
> Regards
> Thomas
>
>
>
> ==================================================================
> stat
> params: ( path:string [ rev:number ] )
> response: ( ? entry:dirent )
> dirent: ( name:string kind:node-kind size:number has-props:bool
> created-rev:number [ created-date:string ]
> [ last-author:string ] )
>
>
> =======================================================
>
>
>
> log
> params: ( ( target-path:string ... ) [ start-rev:number ]
> [ end-rev:number ] changed-paths:bool strict-node:bool
> ? limit:number
> ? include-merged-revisions:bool
> all-revprops | revprops ( revprop:string ... ) )
> Before sending response, server sends log entries, ending with "done".
> If a client does not want to specify a limit, it should send 0 as the
> limit parameter. rev-props excludes author, date, and log; they are
> sent separately for backwards-compatibility.
> log-entry: ( ( change:changed-path-entry ... ) rev:number
> [ author:string ] [ date:string ] [ message:string ]
> ? has-children:bool invalid-revnum:bool
> revprop-count:number rev-props:proplist
> ? subtractive-merge:bool )
>
>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> > Gesendet: Montag, 19. September 2011 13:41
> > An: Stümpfig, Thomas
> > Cc: users_at_subversion.apache.org
> > Betreff: Re: SVN File Size
> >
> > Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +0000:
> > > Hi all,
> > > First of all, I would like to thank you for your dedication to this
> > issue
> > > I would like to resume:
> > >
> > > a) there is work on serverside in 1.7 that cares about file size
> > > b) svnlook filesize makes use of it in 1.7
> >
> > IIRC, in 1.7 svnlook simply exposed a long-existing FS API.
> >
> > > c) there might be issues related to svn:eol and svn:keywords
> >
> > The FS returns the length of the repository-normal form, i.e., LF
> > linefeeds and contracted keywords.
> >
> > > d) It is worth to create a ER for svn log
> > >
> >
> > I'm not sure; where do you draw the line between 'svn log' and 'svn
> > info'?
> >
> > > I will try to dig into the code and see if I am able to understand,
> > the rough structure of it.
> > > Where should I look to, as a starting point? I am not anymore so
> > fluent in C but I will try my best.
> > > For sure I should know more details about the architecture, but I
> > would like to concentrate on the part that
> > > deals with this one.
> > >
> >
> > First of all you should determine whether your patch needs to extend
> > the
> > wire protocol or not. See subversion/libsvn_ra_svn/protocol or
> > subversion/include/svn_ra.h
> >
> > > Regards
> > > Thomas
> > >
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stefan Sperling [mailto:stsp_at_elego.de]
> > > > Gesendet: Freitag, 16. September 2011 10:43
> > > > An: Stümpfig, Thomas; users_at_subversion.apache.org
> > > > Betreff: Re: SVN File Size
> > > >
> > > > On Fri, Sep 16, 2011 at 10:31:05AM +0200, Stefan Sperling wrote:
> > > > > So what you're asking amounts to either a performance hit for
> > 'svn
> > > > log'
> > > > > or to a new feature in the filesystem (record the size of the
> > full
> > > > > text of a file along with the changed-path data which 'svn log'
> > > > reads).
> > > >
> > > > Ooops, I was wrong here, sorry. The expanded size of the full text
> > is
> > > > already recorded in the filesystem. As Johan pointed out, there is
> > > > 'svnlook
> > > > filesize' which prints this number (which is stored in the FS, so
> > there
> > > > is no need to compute it). There wouldn't be a performance hit for
> > 'svn
> > > > log'.
> > > >
> > > > The below is still valid as-is:
> > > >
> > > > > I think the feature you are requesting is reasonable.
> > > > > If you like, you can file an 'enhancement request' issue in our
> > issue
> > > > > tracker about this. Maybe somebody will have time to work on it.
> > > > > (In case you know somebody who would like to work on this I'd
> > like
> > > > > to point out that we're always happy to help newcomers get
> > started :)
Received on 2011-09-20 00:03:41 CEST