Re: [Gnu-arch-users] Some issues

[Florian Weimer]

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

I've recently been playing with monotone, you know. 8-)

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

Ah.  Although the "interesting" case is the one in which I don't have
write access to the original archive.  In this case "tla commit"
should probably submit the changeset for review, and store it like
"tla undo".  But I admit that such a feature doesn't make too much
sense until there is some kind of intelligent server.

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

This is interesting, I'm going to look at it.

> I don't think that /deleting/ a branch would ever be a good idea
> (something about changing history and having a consistent global
> namespace).

At work, we actual have legal requirements for deletion of most data.
This is quite hard to deal with if you don't use something like CVS
for version control, unfortunately.  I know that such a requirement is
problematic, and most systems today can't support it well (think of
trouble ticket systems, databases, tape backup and so on).

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

Actually, Subversion uses three or four inodes (one for the working
copy, one for the pristine copy, both for file data and properties.
The pristine copy of the file properties can be missing, apparently.).

> 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

But it's so much cheaper to read the data from a single, larger file,
than from lots of different ones.

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