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

[Robert Anderson]

On Mon, 2003-08-18 at 07:46, John Goerzen wrote:
> Hello,
> 
> I have been using Subversion for awhile now (and CVS before that), and
> have found the Arch website -- and it looks appealing.
> 
> However, I have some questions for you -- ones I haven't found answers
> to online.
> 
> 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, and my impression of the consensus is that this is a feature (that
it does _not_ do this), as it simplifies merge semantics.  At the same
time, in a couple years of posts to arch-users, no one has actually had
a use for such a thing that came anywhere close to making it worthwhile
to working out the merge semantics for files which have "forked" like
this.

On the other hand, people pretty much have grown to love some of the
merging capabilities of arch to the point that they will not consider
"going back" to any other system.

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

In arch we say "archive" not repository.  And my first impression is to
say that the size of the archive is essentially irrelevant.  It is
"suitable" for any size archive.

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

arch supports a bunch of transports: ftp, sftp, http, and others.  arch
implements its own locking scheme.  I am not sure what you mean by
"insure integrity."

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

Big in the sense of lots of categories and branches, many which may be
"dead."

  How does that reduce disk consumption?

It doesn't, and it's not supposed to.  Nor does it increase consumption
in any real way.

>    And wouldn't it be easier of the same repository could continue to
>    be used?

Not if you don't want to sift through lots of old categories and
branches.

Bob