fact, BK takes MORE bandwidth than rsync on a 'clone' operation because it
has to ship the complete revision history along.
Wow. Amazing insight, that. You could say "copying 100MB takes MORE
bandwidth than copying 50MB because you have to ship the second 50MB",
and that would be an equally amazing insight.
I think rsync has beaten you to the punch... it's already used to mirror
most of the major source repository out there, and it doesn't care if the
data is source code, tarballs, pictures, or whatnot. It also only
transfers data that has changed, like bk. I will admit that BK is finer
grained that rsync and transfers less uneeded stuff, but they are both
still on the same order of magnitude.
That may be true for small sites, but it doesn't scale. People tend to
update automatically, i.e., out of cron. A null pull of a BK tree will
transfer about 9KB for the whole operation and will stat/open less than
ten files. Rsync will stat *every* file. In other words, rsync places
a load on your server proportional to the number of files, not number of
repositories.
The number of repositories that you could host with BK is orders of
magnitudes higher than the number you could host with rsync, holding
the bandwidth/disks/memory/CPU constant.
It's not rsync's "fault", rsync has no mechanism to know what changed
other than looking at everything, BK records that once at commit time
and then it just knows. Rsync is great at what it does, but that
doesn't mean that what it does is the only thing that needs to be done
nor is it the best way to do it.
The fact that you can host a handful of trees on a machine with lots of
CPU and memory is rather unimpressive. Multiply that by 10,000 and get
back to me.
If I sound sarcastic, good, I intend to be. People being wasteful is
distasteful to me. We live in a world of finite resources and people
constantly think there will just be more. More money, more electricity,
more bandwidth. That stuff is not free, someone is paying for it.
I get the feeling that you, Troy, are just arguing to win the argument
because you want to win. That's called winning the battle and losing
the war. Not widely considered to be a smart approach. How about you
use your smarts to waste less instead of winning meaningless battles?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Larry McVoy [off-list ref] writes:
If I sound sarcastic, good, I intend to be. People being wasteful is
distasteful to me.
And people trying to push their product by inventing problems is
distasteful to me.
Get over it. rsync won.
--
Lars Magne Ingebrigtsen
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun, 22 Jul 2001, Larry McVoy wrote:
quoted
fact, BK takes MORE bandwidth than rsync on a 'clone' operation because it
has to ship the complete revision history along.
Wow. Amazing insight, that. You could say "copying 100MB takes MORE
bandwidth than copying 50MB because you have to ship the second 50MB",
and that would be an equally amazing insight.
Yes, indeed we're comparing apples to oranges (I think that's how you say it in
English, in Dutch we compare apples to lemons :-)
We developers do want the extra 50 MB, but mere mortals don't. They just want a
copy of the latest version of the tree. Hacking is beyond their capabilities.
IMHO, bk en rsync both have their uses.
Gr{oetje,eeting}s,
Geert
P.S. I do agree more or less to the other arguments in your mail, about null
pulls and the scarcity of resources.
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
At 9:07 AM +0200 7/23/01, Geert Uytterhoeven wrote:
On Sun, 22 Jul 2001, Larry McVoy wrote:
quoted
> fact, BK takes MORE bandwidth than rsync on a 'clone' operation because it
> has to ship the complete revision history along.
Wow. Amazing insight, that. You could say "copying 100MB takes MORE
bandwidth than copying 50MB because you have to ship the second 50MB",
and that would be an equally amazing insight.
Yes, indeed we're comparing apples to oranges (I think that's how
you say it in
English, in Dutch we compare apples to lemons :-)
We developers do want the extra 50 MB, but mere mortals don't. They
just want a
copy of the latest version of the tree. Hacking is beyond their capabilities.
Larry, would it be even remotely feasible to add a feature to bk that
checks out just the current state of the tree with no revision
history? Or do repositories have to be identical up to the branching
point of the last mutual push/pull? Maybe it could be done by
creating a special kind of repository that can only pull things from
the parent?
I'm thinking something along the lines of the client having no SCCS
files, sort of like doing a bk export from the server repository to
the client's machine. Unlike export there would also be tag
information for future reference when the server needs to figure out
what's new for the client. You could call the client side command
"bk rsync". :)
I'm way out of my depth here so I have no idea if this is possible or
how much work it would entail.
--
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/