Re: SVN File Size
http://s.apache.org/xy-problem See svn_ra_progress_notify_func_t. Daniel Stümpfig, Thomas wrote on Tue, Sep 20, 2011 at 09:55:09 +: 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...@daniel.shahaf.name] Gesendet: Dienstag, 20. September 2011 00:03 An: Stümpfig, Thomas Cc: users@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 +: 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...@daniel.shahaf.name] Gesendet: Montag, 19. September 2011 13:41 An: Stümpfig, Thomas Cc: users@subversion.apache.org Betreff: Re: SVN File Size Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +: 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
Re: SVN File Size
Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +: 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:s...@elego.de] Gesendet: Freitag, 16. September 2011 10:43 An: Stümpfig, Thomas; users@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 :)
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 +: 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...@daniel.shahaf.name] Gesendet: Montag, 19. September 2011 13:41 An: Stümpfig, Thomas Cc: users@subversion.apache.org Betreff: Re: SVN File Size Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +: 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:s...@elego.de] Gesendet: Freitag, 16. September 2011 10:43 An: Stümpfig, Thomas; users@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
Re: SVN File Size
On Fri, Sep 16, 2011 at 9:59 AM, Stümpfig, Thomas thomas.stuemp...@siemens.com wrote: Hi all, what is the reason that svn log does not tell me the actual file size. I would be more patient ;-), probably as a separate option or within -v All I can find about in the net is a pre/or post commit that does a svnlook cat operation. But this is an expensive operation. The Server should be able to deal with it during the “commit operation”. Help is on the way in 1.7: [[[ -bash-3.00$ svnlook help filesize filesize: usage: svnlook filesize REPOS_PATH PATH_IN_REPOS Print the size (in bytes) of the file located at PATH_IN_REPOS as it is represented in the repository. Valid options: -r [--revision] ARG : specify revision number ARG -t [--transaction] ARG : specify transaction name ARG ]]] This can be used in pre/post-commit hooks to inspect the size of a file. -- Johan
