You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Hammant <pa...@hammant.org> on 2019/06/14 15:22:01 UTC
SvnMerkleizer: announcement
URL: https://github.com/paul-hammant/SvnMerkleizer
It's a Java process that runs alongside Apache and MOD_DAV_SVN to make a
full Merkle tree of the repo. Implicitly too, any sub-directory within. It
attempts to maintain different trees for people with different read
permissions/groups. Coming with it, a Docker image that sets it all up
together. Really that last is a demo, but it does place the SvnMerkleizer
within the same directory structure as the Subversion repo itself. See
within the line of code for that
<https://github.com/paul-hammant/SvnMerkleizer-all-in-one/blob/master/vh-davsvn.conf#L8>
While Svn keeps SHA1 for each file resource within the repo, it does not do
that for directories. Hence I made this tech.
Along the way I created a "service virtualization" tech called Servirtium
that is more interesting to enterprise Java teams than anyone else, but
some of the tests for SvnMerkleizer use Servirtium to record 15K PROPFINDS
and OPTIONS operations and allow them to be used in playback.
Pull Requests accepted.
- Paul
Re: SvnMerkleizer: announcement
Posted by Julian Foad <ju...@apache.org>.
Paul Hammant wrote:
> URL: https://github.com/paul-hammant/SvnMerkleizer
Thanks for sharing, Paul!
- Julian
> It's a Java process that runs alongside Apache and MOD_DAV_SVN to make a
> full Merkle tree of the repo. Implicitly too, any sub-directory within.
> It attempts to maintain different trees for people with different read
> permissions/groups. Coming with it, a Docker image that sets it all up
> together. Really that last is a demo, but it does place the
> SvnMerkleizer within the same directory structure as the Subversion repo
> itself. See within the line of code for that
> <https://github.com/paul-hammant/SvnMerkleizer-all-in-one/blob/master/vh-davsvn.conf#L8>
>
> While Svn keeps SHA1 for each file resource within the repo, it does not
> do that for directories. Hence I made this tech.
>
> Along the way I created a "service virtualization" tech called
> Servirtium that is more interesting to enterprise Java teams than anyone
> else, but some of the tests for SvnMerkleizer use Servirtium to record
> 15K PROPFINDS and OPTIONS operations and allow them to be used in playback.
>
> Pull Requests accepted.
>
> - Paul
Re: SvnMerkleizer: announcement
Posted by Paul Hammant <pa...@hammant.org>.
> 404 Not Found
Yeah, my bad. Was a 'private' repo in GitHub, now public.
Re: SvnMerkleizer: announcement
Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Hello,
On Fri, Jun 14, 2019 at 6:22 PM Paul Hammant <pa...@hammant.org> wrote:
>
> URL: https://github.com/paul-hammant/SvnMerkleizer
>
> It's a Java process that runs alongside Apache and MOD_DAV_SVN to make a
full Merkle tree of the repo. Implicitly too, any sub-directory within. It
attempts to maintain different trees for people with different read
permissions/groups. Coming with it, a Docker image that sets it all up
together. Really that last is a demo, but it does place the SvnMerkleizer
within the same directory structure as the Subversion repo itself. See
within the line of code for that
https://github.com/paul-hammant/SvnMerkleizer-all-in-one/blob/master/vh-davsvn.conf#L8
404 Not Found
> While Svn keeps SHA1 for each file resource within the repo, it does not
do that for directories. Hence I made this tech.
>
> Along the way I created a "service virtualization" tech called Servirtium
that is more interesting to enterprise Java teams than anyone else, but
some of the tests for SvnMerkleizer use Servirtium to record 15K PROPFINDS
and OPTIONS operations and allow them to be used in playback.
>
> Pull Requests accepted.
>
> - Paul
--
With best regards,
Pavel Lyalyakin
VisualSVN Team