[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Some issues

From: Cameron Patrick
Subject: Re: [Gnu-arch-users] Some issues
Date: Wed, 9 Jun 2004 23:37:35 +0800
User-agent: Mutt/

Florian Weimer wrote:
|   <>

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

> 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

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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]