Re: [Gnu-arch-users] Why we might use subversion instead of arch.

[Pierce T . Wetter III]

> > >   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 :-)

  I'm definitely in culture shock which is why I posted. As I said, and 
the FAQs say,
 some documentation explaining that "new take on things" would help 
quite a bit.

  I'm still not really sure I grok arch, and blah--blah--blah isn't 
really helping...

  My issue right now is that any development process needs to decide 
where "truth" lives.

  In CVS land, that is HEAD, from the central server. In our case, we 
use CVS with a pretty
simple model, because revision numbers are meaningless for us. There's 
what's deployed, and
there's what's in development. Periodically, development gets deployed.

  In arch land, you have to decide where truth lives. There's also 
explicit provision for
versions, which ends up confusing me, because I'm not used to thinking 
about versions.

  Though come to think of it, perhaps I'm just trying too hard to use 
arch's "cool" features.
It would be much simpler if I just setup a single shared archive on a 
WebDAV server. Then tla and CVS
are much similar. I'll have to think about that.

>       [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...

 The main rough edge I see is that I think local-mirrors of a remote 
archive should
allow you to commit, with the changes propagating upwards to the 
source. Especially a
greedy mirror.

 Pierce