That was quite a shock. For projects with lots of small changes, it
probably is inconsequential, but for me, on a dialup, it would really
suck.
I use a dial-up and I can't imagine a more dial-up friendly tool than
arch. When I need to merge changes from others, with their own
archives, I typically create a local mirror from them. In updating
my local mirror, I read from them just about the minimum amount of
data that is sufficient and thereafter operate entirely locally. In
combination with a local revision library, operations on these many
archives are just about as fast as can be.
Yeah, I also use a dialup (last person in Japan to do so, I think :-),
which
makes CVS pretty much unusable, but arch is a pleasure.
Note that unlike Tom I only use a local mirror for some archives; for
my
`main' archive, I actually just directly access the remote archive,
and in
most case this is just fine over a dialup. More specifically, using a
local
greedy revision-library (which operates automatically once you set it
up), it
almost always operates `optimally' bandwidth-wise for transferring
changesets, with a small amount of additional latency-bounded overhead
because arch is using a dumb archive (not particularly objectionable).
[I think the main problem seems to be:
(1) A bit of culture shock -- people are so stuck in `CVS mode', that
arch's new take on things takes some time to wrap your head
around
(during which most people seem to post `how arch should be
changed'
messages to this mailing list :-)
[Actually I think it's not really `new', it's the old
patch-files +
lots of trees approach that linux kernel hackers should be very
familiar with, only with arch doing all the annoying grotty work
and
bookkeeping; since I think this approach is really rather _good_
except
for all the grotty work and bookkeeping, I also think arch is
the bee's
knees.]
(2) Arch needs a tiny bit of setup to really work well, revision
libraries
in particular, so a completely raw user may get a bad impression.
[Note for someone setting up a server too, subversion almost
certainly
requires a lot _more_ work!]
(3) Of course there are rough edges, though tla has come a long way
recently...