Re: [Gnu-arch-users] Some issues

[Florian Weimer]

* Michael Poole:

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

It's not the syntax.  A file name might match multiple classification
regexps.  Which match wins?  Can I override the choice with "tla add"?
What's the difference between them, and does it actually matter?

The real trouble is that editing =tagging-method is a very uncommon
operation, but sometimes simply required.  Few developers will know
what to do when the need arises.  Okay, they could ask on a mailing
list when the guy that introduced arch is no longer around.  But I
don't really like such hurdles.

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

Well, much the same thing with the equivalent of shell access, I'd
guess, and the need for UNIX system accounts.

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

But this is exactly what creates stale branches. 8-)

> Besides, how often is a user likely to accidentally use a stale
> branch?

She might think that the branch in the other archive is still live.

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

Yeah, but it's kind of hard to review a changeset in that format
without additional tools.

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

You won't run out of inodes anymore, of course, but every few inodes,
you'll encounter another seek.  This kill performance on cold trees
which aren't in the kernel cache.

(I've changed my position here.  Previously, I thought that cold-cache
performance isn't an isse.  I no longer think that's true.)

>> Project trees should not abuse the file system as a database.
>
> I disagree rather strongly with this.

I mean the checked-out trees, not the archive.  The archive format is
not such a pressing issue, indeed.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.