No subject

[Unknown]

org>
From: Matthew Dillon <dillon at apollo.backplane.com>
Subject: Re: rsync considered superior
Date: Wed, 30 Jan 2008 10:41:54 -0800 (PST)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:users at crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users at crater.dragonflybsd.org>
References: <slrnfoqcit.k9s.vs1 at quark.hightek.org> <478D3794.2040400 at fs.ei.tum.de> <slrnfoqu3g.gd8.vs1 at quark.hightek.org> <478DF803.3000400 at fs.ei.tum.de> <slrnfp0rjk.5v5.vs1 at quark.hightek.org> <4790a882$0$856$415eb37d at crater_reader.dragonflybsd.org> <slrnfp3ctd.fm0.vs1 at quark.hightek.org> <slrnfq06r3.n2j.vs1 at quark.hightek.org> <47A06593.2070604 at fs.ei.tum.de> <47a08d18$0$847$415eb37d at crater_reader.dragonflybsd.org> <47A095D4.30707 at fs.ei.tum.de> <47a0b51a$0$854$415eb37d at crater_reader.dragonflybsd.
org>
Sender: users-errors at crater.dragonflybsd.org
Errors-To: users-errors at crater.dragonflybsd.org
Lines: 30
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1201718854 crater_reader.dragonflybsd.org 856 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.users:10456

    Guys, I just don't care about minor differences in client or server
    cpu use, or bandwidth.

    I think the only real issue here is the one Rahul brought up which is,
    in fact, the original reason why cvsup was written in the first place,
    so cvs tagging wouldn't require a complete redownload of the repository.

    I personally do not think its a big deal.  We do a major tagging
    operation twice a year, and a week or two before the release anyhow
    so there's plenty of time for the servers to work through the update.
    Slip tags only change a few files throughout the year... it's really
    just the pre-release tagging that creates the issue.

    The issue of network bandwidth is more an issue of managing the
    data rate, and not so much worrying about the actual volume of
    information or how long it takes to settle down again as long as
    it isn't too long (like no more then a week or two).

    If it becomes a problem there are plenty of solutions in the pipeline,
    particularly once I start using HAMMER on the servers (which won't be
    soon, but probably some time later this year).  At that point doing
    historical diffs will be trivial and clients can simply supply the
    last 'sync time' (as in a timestamp) and the server can produce a diff
    from then to current, or otherwise tell the client that it can't and
    the client falls back to a normal rsync.  Believe me, it isn't something
    we have to worry about, the solution is just around the corner.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>