I have committed an implementation in http://svn.apache.org/r1857624 , using
Evgeny's new libsvn_fs ioctl API.
It is feature-complete (old and new FSFS formats, revs and revprops, packed and
unpacked.
The CLI is:
$ svnadmin rev-size /path/to/repo -r1
1337 bytes in revision 1
Evgeny Kotkov wrote:
Fixed the typo and committed in https://svn.apache.org/r1857435, thanks!
* We could keep the existing private API declarations in
include/private/svn_fs_fs_private.h as well [...] either way is fine for me.
For now I chose to move the declarations to
Julian Foad writes:
> I have reviewed and tested it. Can you commit?
Fixed the typo and committed in https://svn.apache.org/r1857435, thanks!
> * We could keep the existing private API declarations in
> include/private/svn_fs_fs_private.h as well as the new ioctl versions of
> them, rather
Evgeny Kotkov wrote:
Maybe, as an alternative to abstracting and promoting this to a public FS API,
we could add a way of performing backend-specific I/O operations through an
API like svn_fs_ioctl()?
Thanks, Evgeny! I like it. Keeping clean modularity is important.
See the attached patch
Julian Foad writes:
> Similar consideration applies to the API. I think this could be a libsvn_fs
> API rather than only in libsvn_fs_fs. Agreed?
Maybe, as an alternative to abstracting and promoting this to a public FS API,
we could add a way of performing backend-specific I/O operations
On 09.04.2019 17:53, Julian Foad wrote:
> Branko Čibej wrote on 2019-04-09:
>> Is there a reason why this would be hidden away in 'svnfsfs' instead of
>> 'svnadmin'? Other than that the latter would have to return 'something'
>> for BDB repositories.
> I am wondering the same.
>
> We've deprecated
Branko Čibej wrote on 2019-04-09:
> Is there a reason why this would be hidden away in 'svnfsfs' instead of
> 'svnadmin'? Other than that the latter would have to return 'something'
> for BDB repositories.
I am wondering the same.
We've deprecated BDB support so I think we don't need to
On 09.04.2019 13:23, Julian Foad wrote:
> I am working on an API to report the size on disk of a given revision, in
> FSFS. A client wants this for (human) informational purposes -- so users or
> administrators can understand how much space their commits are using.
>
> Before FSFS f7, this
Julian Foad wrote:
[...]
> * simplify implementation by using the existing
> svn_fs_fs__dump_index() API with a simple callback
Here's v2, functionally identical, with that simplification.
--
- JulianAdd an API and CLI to report a revision's size on disk.
### So far, this patch only works
I am working on an API to report the size on disk of a given revision, in FSFS.
A client wants this for (human) informational purposes -- so users or
administrators can understand how much space their commits are using.
Before FSFS f7, this information was easy to obtain from the on-disk size
10 matches
Mail list logo
