DragonFly users List (threaded) for 2008-01
DragonFly BSD
DragonFly users List (threaded) for 2008-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: rsync vs. cvsup benchmarks

From: Vincent Stemen <vince.dragonfly@xxxxxxxxxxx>
Date: Wed, 30 Jan 2008 16:38:31 -0600

On Wed, Jan 30, 2008 at 09:54:29AM +0000, Rahul Siddharthan wrote:
> As I understand, cvsup maintains state between updates using checkout
> files in a separate "sup" directory.  If you are missing that
> directory, or it does not correspond to your "aged" tree, cvsup won't
> do very well.  You should test cvsup by checking out the tree, waiting
> a week (or whatever the time is) to age it, and then updating it. 
> Likewise for rsync (though it doesn't require a checkouts directory). 
> Rahul

That's a good point.  It is possible that cvsup would fair better with
a matching sup directory.  I actually forgot about cvsup keeping that
separate state directory when I ran the benchmarks.  However, from my
viewpoint that does not invalidate the test results or convince me that
there is any reason I would want to use cvsup for mirroring because of
several reasons.

  1 The state directory would have to make cvsup almost 4 times as fast
    to even match rsync's average performance, which I think is
    unlikely, considering it was only half as fast on a full download
    starting with an empty repository, and did not even match rsync on
    any of the update tests.

  2 Rsync did not have the benefit of a local state directory either, so
    it was a one on one fair comparison.  Based on all the cvsup claims,
    I would have expected it to at least come close to matching rsync's
    performance.  Then I would expect a higher possibility of it being
    faster than rsync with the state directory available.

  3 I think doing the comparison under robust conditions, and not under
    fragile or undependable circumstances is more realistic.  For
    example, if you do an rsync update in between, your state directory
    is no longer going to match.  I would not even trust the state
    directory not to break if you have to do an update using cvsup from
    a different server because the one you used last time is down.  This
    is also the reason I did not include the '-s' switch to cvsup (which
    is also supposed to increase performance), because in the manual, it

        "If the -s option is used when one or more files have been
        modified locally, the results are undefined.  Local file dam-
        age may remain uncorrected, updates may be missed, or cvsup may
        abort prematurely."

    I consider that to fragile.

  4 All these fragile conditions to get cvsup up to maximum performance
    only applies to cvs repositores.  If you ever decide to use
    a different revision control system...

Considering the fragile nature and non-portability of cvsup, I am not
very interested in using it even if it was a little faster than rsync.
So I don't really have the time or motivation to generate benchmarks
with the cvsup state directory.  The way that would have to be tested
would require weeks, and a lot more headache, generating and keeping all
the matching state directories for each test.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]