[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Questions from a Subversion user
From: |
Andrew Suffield |
Subject: |
Re: [Gnu-arch-users] Questions from a Subversion user |
Date: |
Mon, 18 Aug 2003 16:44:09 +0100 |
User-agent: |
Mutt/1.5.4i |
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
Re: [Gnu-arch-users] Questions from a Subversion user,
Andrew Suffield <=