DragonFly users List (threaded) for 2008-01
From: Matthew Dillon <firstname.lastname@example.org>
Subject: Re: rsync considered superior
Date: Wed, 30 Jan 2008 10:41:54 -0800 (PST)
References: <email@example.com> <478D3794.firstname.lastname@example.org> <email@example.com> <478DF803.firstname.lastname@example.org> <email@example.com> <4790a882$0$856$415eb37d@crater_reader.dragonflybsd.org> <firstname.lastname@example.org> <email@example.com> <47A06593.firstname.lastname@example.org> <47a08d18$0$847$415eb37d@crater_reader.dragonflybsd.org> <47A095D4.email@example.com> <47a0b51a$0$854$415eb37d@crater_reader.dragonflybsd.
X-Trace: 1201718854 crater_reader.dragonflybsd.org 856 126.96.36.199
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.