svn - but smaller?

[Markiyan Kushnir]

Hi John,

I also measured svnup basic process resource usage, attaching a complete 
plot (measurements were taken each 2 seconds based on ps(1) and 
procstat(1)). Hopefully it will help you as well.

--
Markiyan.

On 31.03.2013 12:51, Markiyan Kushnir wrote:
> On 25.03.2013 02:55, John Mehr wrote:
>>
>>
>>
>> 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.
>
> Hi again!
>
> Yes, I agree that svn editor needs quite a bit of effort. I was actually
> encouraged to break this challenge, and made my own svnup based on
> svndiff. If you are interested in details, you may find it on github.com
> under mkushnir/mrksvnup. It's a complete app, although you may use or
> re-use (parts of) it if you want.
>
> I also tested your svnup more and found that it doesn't handle symbolic
> links well. (May be you have already been aware of it.)
>
> I would suggest to test svnup against official svn client. Here is
> briefly what I'm doing to test my own svnup:
>
> # svn co -r NNNNNN svn://svn.freebsd.org/base/head head.svn
> # svnup -u svn://svn.freebsd.org/base/head -r NNNNNN -l head.svnup
> # diff -r head.svnup/ head.svn | egrep -v 'FreeBSD|\-\-\-|^diff
> \-r|^[0-9]+c[0-9]+'
>
> The diff output must be clean.
>
>
> --
> Markiyan.
>
>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>