Re: [Gnu-arch-users] Questions from a Subversion user

[Andrew Suffield]

On Mon, Aug 18, 2003 at 09:46:44AM -0500, John Goerzen wrote:
> 1. Does arch support "shallow" or "copy on write" copies like
>    Subversion does?  For instance, if I have a file foo.c, I can run
>    svn cp foo.c bar.c.  bar.c will not have to duplicate foo.c's data
>    on-disk, and moreover, knows its history.  Changes to bar.c will
>    just create a delta from the version of foo.c from which it was
>    copied.
> 
>    Can Arch do this as well?

No; one-to-many file branches are a broken idea that makes merging
extremely difficult: when you merge a change to that file, made on a
different branch to the one where you forked it, which one should it
be applied to? (Subversion "solves" this by not supporting merging in
a useful fashion). I've never heard a concrete reason for why this is
useful; the extra bit of delta-compression will be insignificant.

> 2. How suitable is Arch for large repositories?  (I'm talking here in
>    the 100MB to 1GB range)  If it is unsuitable, why, and how does it
>    compare to Subversion or CVS for these?

A lot of people will talk about this at great length, and nobody
actually knows, because they've never actually tried it (although a
few people have constructed artificial test cases which will prove
anything you like). There's no reason to think it will be as slow as
subversion for this, though.

> 3. One thing that makes me nervous is that Arch appears to be based on
>    FTP.

(It isn't, it's based on unix files)

>    As we all know, FTP has zero features for implementing any
>    sort of reliable locking.

*You* might know this, but it's not true. There are some atomic
operations which can be used for locking (rename and mkdir, iirc).

>    How does Arch insure repository
>    integrity over such a protocol?

You really shouldn't be using the ftp transport for writing to the
repository. Use something vaguely secure like sftp or webdav+ssl
instead.

> 4. A lot of documentation talks about people making new repositories
>    each year because old ones get "big".  Why do people need to make
>    new repositories annually?  How does that reduce disk consumption?
>    And wouldn't it be easier of the same repository could continue to
>    be used?

I've never seen a convincing reason for why you should do this - so
I'm not planning on doing it. I think it's just Tom's perversion. Much
like some people archive their home directory every year, because they
let it get cluttered.

I suppose that theoretically the directory would eventually grow so
large that getting a list of files would be a significant performance
penalty. But that certainly shouldn't happen within a year.

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

pgptX_bqHSiYJ.pgp
Description: PGP signature