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

[Bruce Stephens]

John Goerzen <address@hidden> writes:

[...]

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

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

Repository size (archive size) is unimportant to arch.  Things are
stored in separate files, so when you import your sources, they go
into a .tar.gz file, and patches also go into .tar.gz files.  So for
most operations, it's more important to know how many files there are
in your project.

> 3. One thing that makes me nervous is that Arch appears to be based on
>    FTP.  As we all know, FTP has zero features for implementing any
>    sort of reliable locking.  How does Arch insure repository
>    integrity over such a protocol?

It relies on things like mkdir and rename, and it's designed to work
well on typical filesystems (excluding NFS, probably), and over things
like ftp (sftp, for example).

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

It's the number of revisions, I suspect.  If you imagine constructing
the current revision of a project, you might start from the first
import, and then apply the patches one by one.  And that's expensive.
Arch has ways to make that faster (you can cache full copies of any
revision, and you can use a revision library, and it automagically
caches things (although this is all likely to change shortly)).  Even
so, a number of things become more costly if your archive contains
large numbers of categories/branches/versions/revisions.

> Incidentally, what is the relationship between Arch and the FSF?  Is it now
> an official GNU project?  Does that mean any practical differences for the
> project?

Yes and probably not much.

[...]