Re: [Gnu-arch-users] Some issues

[Michael Poole]

Florian Weimer writes:

> I've finally collected a few issues that might be the reason why I
> back away from tla each time I start using it again, despite being
> always excited by it when reading about it.
>
>   <http://www.enyo.de/fw/software/arch/design-issues.html>

>From that page:
> 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.

What makes this hard to deal with?  I admit that I'm a programmer by
trade and have more than passing familiarity with regular expressions,
but it seemed pretty natural to me.  I'm not sure why a simpler syntax
(for example, shell-style globs) would be significantly easier for
novice users.

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

Can you elaborate on what is missing?  Several projects, including one
that I work on, use arch with a central archive and several committers
to that archive.  The only problems we have seen have been when
someone uses the wrong umask, and leaves a directory with mode 0755.

> Branch creation is not versioned. Branches cannot be deleted. This
> means that branches stay around forever, even after development on
> them has finished.

I don't see how this is a design defect.  If you want to start fresh,
use a new archive -- don't try to change history and deny the branch
existed.  Besides, how often is a user likely to accidentally use a
stale branch?

> Changesets are tar files. They cannot be posted easily to a mailing
> list for approval and commit; metadata tends to get lost.

How so?  If you have the tar file, you can use show-changeset to get a
summary of the changes or apply it to your tree.  I have not plumbed
the details of some of the files and directories in a changeset, but
most of them seem to be there for a reason.

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

ITYM "gratuitous" rather than "gracious."  My arch-native projects use
tagline tagging, so I only need two inodes per file.  But even at four
inodes and two full copies per file, I would likely never run out of
inodes or space: disk is cheap and, at least on my machines, abundant.

> Project trees should not abuse the file system as a database.

I disagree rather strongly with this.  I *like* how arch is generally
agnostic about its repository access mechanism.  It also makes it
feasible to reconstruct the history or even commit changes if you only
have access to the filesystem, rather than needing some additional
tool to inspect or change a database with opaque structure.

Michael