[Top][All Lists]

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

Re: [Gnu-arch-users] the state of the union

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] the state of the union
Date: Thu, 19 Aug 2004 09:31:17 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Greg Hudson wrote:

In FSFS as well, a commit is finalized by bundling up the transaction
directory into a file and storing that in the revs directory, after
which time the file never changes.

So it's a form of changeset, then?

Client-side caches and memos are a flexible solution that scales
arbitrarily with the number of clients.


Here's something I do often: I find a bug in one of the dozens of
upstream programs I maintain builds of, and I narrow it down to a
particular source file.  My first question is "is there an upstream
fix?"  So I ask the upstream CVS repository for a log (or in some cases
a blame annotation) of the upstream file.  I'm not going to have a
well-populated client-side cache for the given program.  The upstream
repository would probably rather not serve me the project's entire
version history, and I certainly would rather not have my client pore
through that entire history.

In Arch, a well-populated client-side cache isn't required in order to read the log, because the log is stored as a plain file in the archive. The log contains data about which files are modified by the associated changeset, which may be all you need. If you need blame annotation, Arch doesn't have that, yet.

On a non-local filesystem, this will be slower than a smart server could achieve, but still quite feasible.

Worst of all, though, how are your users supposed to _recognize_ when
a Subversion archive has been corrupted?

Uh, does that have *anything* to do with the debate at hand?  The answer
to that would seem to depend on whether developers are signing their
commits, not whether the archive is accessed through a dedicated server
or a dumb file transport.

Not "corrupt" in the sense of "subverted", but corrupt in the sense of "invalid". With plain files and a simple format, it's pretty easy to detect invalid revisions and to fix some forms of corruption.


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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