Re: svn - but smaller?

2013-04-13 Thread mrboco
In the previous version (0.61), the process of checking file names against the list of known files in the repository was inefficient and most likely accounts for the slow down you're seeing.  I've reimplemented it using a binary search tree and the lookup phase is no longer a

Re: svn - but smaller?

2013-04-12 Thread mrboco
On Friday, April 12, 2013 1:28:43 PM UTC+6, Markiyan Kushnir wrote: It would be nice to get comparable time from svnup. I think we could get comparable time only with svn. Sorry. ___ freebsd-stable@freebsd.org mailing list

Re: svn - but smaller?

2013-04-11 Thread mrboco
On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote: 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:

Re: svn - but smaller?

2013-04-11 Thread mrboco
On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb...@gmail.com wrote: I've placed the patched svnup.c (0.56), the diff and two statically linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ I'm sorry, svnup.c.diff is the patch against filtered thru indent svnup.c, with different

Re: svn - but smaller?

2013-04-11 Thread mrboco
I'm sorry, but even ignoring all of your whitespace and style(9) differences, your patch appears to go well beyond correcting a typo, which I can't spot anyway, though I'm sure John will know what it is. Care to explain a little more? Sure. Typo is strlen(command - total_bytes_written)

Re: svn - but smaller?

2013-04-11 Thread mrboco
On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan Kushnir wrote: Another thing that might be worth of attention, the patched version has been again back to slower checkout time: real91m38.824s user0m26.216s sys 0m13.858s at 4 Mbit/s link, while the original 0.56 takes