Hi Daniel,
The reason for file size in 'Svn log' would be to easily estimate the amount of an update operation. It is already in 'svn list' which helps for "checkout and export". Let's assume you work offline for a week. Your colleague commits many jpg's, or tutorial avis to the documentation directory.
You are unaware of this since you just update your project directory. If you're on a WAN bandwidth you will have to wait or interrupt, and probably svn cleanup. Things I do not really like.
I agree, one could script around and produce deltas of 'svn list', but I would expect this in core. Sure it's not an obvious use case, but this would definitely help my guys to work smoother with svn.
I still will have to convince TortoiseSVN to calculate filesize for directories in the Browser and in logsummery.
With respect to the question of how to implement I would appreciate any input, since I am a newbie in svn programming.
Regards
Thomas
> -----Ursprüngliche Nachricht-----
> Von: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Gesendet: Dienstag, 20. September 2011 00:03
> An: Stümpfig, Thomas
> Cc: users_at_subversion.apache.org
> Betreff: Re: SVN File Size
>
> 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 11:56:30 CEST