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

[Tom Lord]

    > From: "Pierce T. Wetter III" <address@hidden>

    >   Note: The purpose of this email is not to rile you guys up. Its for me 
    > to document my findings about arch, so that either you can correct my 
    > errors, or so you can improve arch, since I really liked the 
    > distributed nature of it.

    >   Background: [....]
    >   Our setup: [....]
    >   Our work process: [....]

Very much a situation that arch can help with both in ways you've
anticipated and in ways you haven't.



    >   Now for the bad stuff:

    >   Ok, so I tried experimenting with arch. The first thing I did was 
    > check out something from a public arch repository. I got quite a shock. 
    > Evidentially, every arch repository stores the "base code", then 
    > follows that with a series of forward patches. This is quite different 
    > from most other version control systems, which store the head version 
    > as "truth" and then keep reverse patches going backwards. The net 
    > effect of this is that checking out that version required downloading 
    > not just the latest code, but downloading all the patches in between.

That's not quite true.   Arch is actually quite flexible in this area
and is becoming more so.

What you've described could be called the "baseline behavior" of arch
archives.  If nobody takes any other steps, things work as you've
described.

However, arch has a some facilities that change that baseline
behavior:  

"Archive revision caching" is one mechanism -- see `tla cacherev -H'.
That can spare you from downloading all of those intermediate
revisions.

"Revision libraries" are another mechanism.   They can spare you from
having to build various historic revisions that arch may need during
its operation.

"Local mirrors" are another mechanism.   They can help you minimize
network costs.

In practice, I think most arch users are like me and use a combination
of those to get very good performance.   The specific combination of
those features that's best for your situation varies depending on your
network and hardware topology and usage patterns.

You talk about the specific example of checking out an existing arch
project.   Mine (since I don't archive cache revisions very often)
would have behavior more or less like what you describe.   But please
keep in mind that a remote checkout from an archive like mine is _not_
how you would normally use arch -- certainly not how you would use it
day to day in a work situation such as the one you described.

Instead, most likely, you would create a local mirror of the remote
archive.  Periodically, you would update your mirror.   Most likely
you would set up a local revision library.   In that circumstance,
you'll pay a steep cost _once_ -- to set up your mirror and library
(to "prime the pump", so to speak) and after that, arch's behavior
will be much more like what you expected in the first place.
Actually, it will often be better than what you expected.



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


    > Now I read some stuff on the wiki about how you can make all that 
    > faster by making a new archive (which moves the base), but I shouldn't 
    > have to change my work process to make the version control system 
    > efficient.

You aren't really moving the base -- you're just mirroring it
locally.  It's a foreign concept if you are used to CVS but, once you
get the hang of it, you'll find that it's fast and convenient.


    >   The next thing I noticed was that while CVS and Subversion let you 
    > structure your projects and sub projects via the filesystem, arch 
    > really tries to grab the whole filesystem as one unit. You can override 
    > this a bit, but it involves setting up some config files. Config files 
    > that are kind of poorly documented (based on the fact that I couldn't 
    > make heads or tail of the explanation). This makes a lot of sense for 
    > open source projects focused on a single executable, but makes much 
    > less sense for us. I suspect most people deal with this but just having 
    > lots of arch repositories:

    >     /archrepositories/blessed/tool
    >     /archrepositories/blessed/library
    >     /archrepositories/blessed/application

    >   But that would be a nightmare for us.

I wonder if, at your shop, you have someone whos job it is to manage
your process and set up tools that make it easy for developers.

Far from being a nightmare, _if_ you can get over the initial hump of
figuring out how to set things up, I think you'll find that arch
enhances your processes and makes them work better.


    >   The next thing I found was that it was SLOW. tla is kind of brute 
    > force, and all that diff-ing, tar-ing, and compressing can take quite a 
    > while.

It does take a little bit of care to set up a tla environment that is
fast but many people have done so successfully.   Once you do so, I
think you'll find many advantages compared to CVS and SVN -- but it
does take some care.


    >   So at this point, while the distributed repository stuff was cool, I 
    > had to conclude that arch works best for working on open-source 
    > development where you don't submit code so much as you submit patch 
    > files, and you need to merge patches from multiple places. From that 
    > point of view, arch is great. From ours, ugh.

I think you are overlooking how similar the workflow you've described
is to "open source stuff".


    >   How I would improve arch:

    >     Fundamentally, I think that arch should store HEAD, with reverse 
    > patches, rather then START with forward patches.

Arch already allows you achieve, in essense, the same effect.   You
just need some help deploying it in your environment.


    >     The rsync protocol would make more sense then webdav or ftp.

For mirroring?   You can already use rsync.

    >     Improve the documentation, especially needed is a section with some 
    > arch concepts, so that you don't have to pick up everything by osmosis.

Yup.   In the meantime, you might consider a small-scale consulting
gig for one of the experienced arch users.   I would hope that you can
find someone on the list who can help you with your evaluation and
prospective infrastructure design for a few hundred bucks.


-t