Re: [Gnu-arch-users] Some issues

[Cameron Patrick]

Florian Weimer wrote:
|   <http://www.enyo.de/fw/software/arch/design-issues.html>

Some valid criticism there.  You missed out the main one that I found
when I first started using arch, which was that the tla command line
syntax is hideous.

> Arch does not implement a distributed system. For example, its archive
> replication does not transparently handle write operations.

Aaron Bentley's branch claims to support this (though I haven't got
around to trying it yet).  http://sourcecontrol.net/~abentley/integration.php

> The idea to automatically subject files to revision control, based on
> regular expressions, is very hard to deal with for users. While being
> an interesting experiment, it does not lead to increased usability.

I presume you're referring to the "names" tagging method?  I agree
that it has problems, but it also has its uses and it is just one of
the three tagging methods supported by arch -- not even the default
one.

> GNU arch does not support a centralized development model which lacks
> a single, designated committer.

Yes, it does.  I use it that way with no problems.

(The initial set-up required being careful with umasks though, and
it'd be really great if arch would support the concept of a
"per-archive umask" that it would set before writing to an archive.
Perhaps it would be better to see this implented at a filesystem level
but I don't think it'll happen -- although ACLs may come close.)

> Branch creation is not versioned. Branches cannot be deleted. This
> means that branches stay around forever, even after development on
> them has finished. (This could be worked around in the implementation
> by hiding branches, but it doesn't seem to be the right thing to do.)

This is kludged around by archive cycling and "sealing" branches
(which hides them from the abrowse command).  I don't think that
/deleting/ a branch would ever be a good idea (something about
changing history and having a consistent global namespace).

> In practice, tla requires four inodes per file in a checked-out
> project tree: one for the file, one for the file ID, and a a pristine
> copy of both. This gracious use of inodes can cause problems.

*shrug*  It's only twice as many inodes as svn uses.  It could be
improved, though, but I don't see "lack of inodes" as being a serious
problem.  My /home partition is a bog-standard ext3 FS and it is 70%
full space-wise and only 18% full inode-wise.  I suppose it'd be more
of a problem if a filesystem was used only to store arch trees, but
who does that? :-P

> Redesign the changeset format, probably based on VCDIFF (RFC 3284).

Ewww!

> Do not expose the archive format, but use a changeset server which
> implements access control (and pipelining, to cut down effects of
> network latency).

This would be nice, as an optional feature; but being able to run
without having to set up anything on the server is one of the things
that I like about arch.

Cameron.