Re: [Gnu-arch-users] Some issues

[Andrew Suffield]

On Wed, Jun 09, 2004 at 04:03:27PM +0200, Florian Weimer wrote:
> 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>
> 
> I know that for some of those issues, workarounds exist, and that in
> several cases, the general consensus on this list is that the issue is
> not a problem at all.  If there are some good rebuttals of individual
> points I might add links to them.

> The changeset format is defined relative to GNU patch and GNU
> tar. These data formats are still somewhat in flux.

What? I'm not aware of anything more stable than these.

> The changeset format does not handle binaries efficiently, and
> certain text files (e.g. XML files not created by a text editor and
> formated for readability).

Right, nothing does. Unsolved problem. Nothing to do with
tla. Supporting this would be fairly easy if the problem were ever
solved.

> In essence, an archive consists of concatenated changesets, which
> are directly exposed in a file-based interface. This makes it very
> complex to address issues with the changeset format itself, and the
> archive interpretation might change when new versions of patch and
> tar are installed.

"In the future, tar and patch might have critical, fatal bugs."

Obviously true, but nothing to do with tla. Any component on your
system may suddenly develop critical, fatal bugs on some future
upgrade. That's why we have vendors - to create collections of
specific package versions that are known to work reasonably well
together.

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

Sophistry. I think this is a reference to a changeset which is pending
but which Tom has not yet merged, adding this fairly trivial feature.

> There is no integrated mechanism to atomically commit related
> changesets to two branches (even if these branches are contained in
> the same archive).

I can't imagine why you would want that. Nor have I ever heard of
anything which implements it. But Tom appears to know how to implement
it.

> Categories, branches, and versions are not orthogonal at all and add
> unnecessary complexity. Future features cannot differentiate between
> them because they are used very inconsistently in existing archives.

No idea what that is supposed to mean. They're just names. Almost
everything just wants a version specifier, and doesn't care about the
fact that the '--'s in the string have significance.

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

So don't use it.

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

False. Not that this model is a good idea. Most large projects eschew
it.

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

Eh? *Nothing* can be deleted, and that's half the point. This is a
significant feature.

> The archive format optimizes for access to early versions, not most
> recent ones as one would expect.

False. The archive format doesn't optimise for anything. Clients do
that, and tla can do several things.

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

Wrong in all but the first point. I've never seen a mailing list which
didn't support MIME. And you don't normally want to do this anyway -
you want to post a revision name.

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

Handwaving.

> A checked-out revision of a branch contains at least one inode for
> each revisions that was ever committed in the history of the
> branch. Long-running branches also result in huge directories with
> lots of entries.

So? I've never heard of anything which approached the point where
directory size becomes an issue (upwards of 100k directory
entries). You've got serious intrinsic problems if you have 100k
revisions on a single branch, and no amount of software will help you
with that.

> The inventory code can create inconsistent results. For example,
> explicit tagging only overrides classification based on regular
> expression in some (but not all) parts of tla.

What?

> The inventory constructor, project tree checker, and changeset
> creation code are not fully synchronized. For example, it is
> possible to commit a changeset with an inconsistent inventory, which
> is also inconsistent as a result.

This is a reference to two known bugs, which are slated to be fixed in
1.3. They're fairly simple bugs.

> Branch creation is very cheap (a few inodes in the archive), but a
> long-running branch to which changes in a mainline branch are
> periodically merged replicates all changes on mainline. This means
> that branch maintenance costs are controlled by the amount of
> development on the branch and the development on the mainline, and
> branches are no longer very cheap in total.

Can't see why you think this is a problem. "Cheap branches" means that
they're created cheaply, not that they magically decrease the size of
deltas committed to them.

> The GNU arch developers believe that it's easy for all developers
> participating in a project to publish a repository.

Indeed, trivially true. See sourceforge, savannah, sourcecontrol, etc.

> However, this requires write access to webspace without file name
> and directory layout limitations.

False.

> Such resources are often not available in a corporate environment,
> or to those who can only afford cheap Internet access.

Also false, see above.

> Genuine support for centralized development is required, but GNU
> arch is unlikely to provide it.

Sophistry.

> The developers seem to underestimate the need for a robust user
> interface with clear error messages and transaction semantics
> (i.e. a command either fails and changes nothing, or it completes
> successfully).

Handwaving.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature