svn - but smaller?

[John Mehr]

On Sun, 24 Mar 2013 05:55:19 +0200
 Markiyan Kushnir <markiyan.kushnir at gmail.com> wrote:
> Hello John,
> 
> Tested svnup for a while, and I can say it does its job 
>well, and works basically as I would expect, so thanks 
>for your initiative. Although it appears to be quite 
>resource greedy. Most of the time it showed something 
>like:
> 
>  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C 
>  TIME   WCPU COMMAND
> 22270 mkushnir      1 102    0 44944K 31804K CPU0    1 
>  6:22 97.56% a.out
> 
> 
> I looked at the source code, and found that it uses svn 
>commands that are known as the "main command set". The 
>program is implemented around get-dir and get-file. I 
>think there is significant room for resource and 
>performance improvement.
> 
> Have you considered an approach to use what svn folks 
>call the editor command set? I mean acting as a trivial 
>svn client: we might ask the server to drive our checking 
>out or updating. The server will be telling us only 
>diffs. Checking out a full tree would be just another 
>diff, although bigger than usually. We would also benefit 
>from compression on the wire.
> 
> Another advantage would be to always have consistent 
>repo more-or-less guaranteed by the svn server.
> 
> I've done some proof of concept recently, and the 
>results look encouraging to me. For example, a do-nothing 
>update really does nothing. A two-or-three revisions 
>update takes a couple of seconds. And a full checkout of 
>the base/stable/9 takes ~7m30s at 530kB/s to me.

Hello,

The results I was getting from testing out the svn 
protocol's editor command set were unpleasant enough to 
put it into the "come back to this later" category while I 
worked on implementing the http/https side.  The good news 
it that the http side is *much* easier to work with in 
this respect and getting a report with filenames and 
MD5/SHA-1 signatures for all of the files in the 
repository can be obtained all at once.  I should have a 
new and improved version ready to go this weekend or early 
next week at the latest.