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

[Andrew Suffield]

On Fri, Feb 20, 2004 at 10:45:39AM -0700, Pierce T. Wetter III wrote:
>  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 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. 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.

See cacherev. You're not supposed to build up a long series of
revisions without scattering some cached revisions along the way.

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

Not really. Configs are optional automation. Filesystem structure
happens on the client.

> I suspect most people deal with this but just having 
> lots of arch repositories:

"Archive", not "repository", and no. You just have lots of categories
in one archive. So you have tool--main--1.1,
library--development--1.2, etcetera, and on your client workstation
you can nest the trees if you feel like it. A config is then just a
way to perform an operation on a big stack of nested trees at once.

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

Unnecessary. You can layer this over the top quite easily, by having a
commit hook that cacherevs the latest revision and uncacherevs the
prior one.

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

And be impossible to use directly. See tla-rsync-mirror, though (which
is "safe enough" so long as you don't try to simultaneously update the
mirror with tla-rsync-mirror and archive-mirror).

>    While tla is ok as a low-level tool, I've observed that everyone 
> keeps trying to replace it with a driving script. That's a good 
> instinct. For one thing, I think that:
> 
>   user--archive--task
> 
>   is harder to read then:
> 
>  tla make-archive --id address@hidden  --name archive
> 
>  tla archive-setup --project hello-world --branch mainline --version 0.1

You have too much time on your hands.

>  It would be a trivial change to tla to support passing archive names 
> as individual parameters, but I think it would flatten the learning 
> curve of arch. Especially since I think that if you break up the names, 
> you can realize that it would be pretty easy to come up with standard 
> defaults for most of these, such that you only have to type:
> 
>  tla archive-setup --project hello-world
> 
>  because branch defaults to "mainline", and version defaults to 1.0.

Unrelated. Done that, anyway.

>  Something I'd also like to see that I implied above:
> 
> doesn't currently have any concept of a "master" repository, I think it 
> makes sense that the high-level commands would support this concept 
> that you have local archives you can commit to all the time, with a 
> remote archive you commit to less often.

Impractical. It won't make sense for most people. This sort of thing
is acutely site-specific.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature