gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Re: planning 2.0? (was re: Google...)


From: Nathaniel Smith
Subject: [Gnu-arch-users] Re: planning 2.0? (was re: Google...)
Date: Fri, 21 Apr 2006 10:01:54 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Thomas Lord <lord <at> emf.net> writes:
>    By "definition", anything to be called Arch is:
> 
>      ~ a revision control system
>      ~ using a decentralized database
>      ~ supports replication of database nodes
>      ~ operates well with "partial knowledge" (some nodes inaccessible)
>      ~ supports easy branching and merging across separately
>         administered database nodes which exchange only read-only rights
>      ~ provides ACID properties to multiple users of a single database
>         node
>      ~ provides smart merging based on history-of-patches and
>         common-ancestor computations
>      ~ handles file renames during merging via logical file ids
>         rather than tracing history
>      ~ permits publication of database nodes using generic,
>         commonly provided server-side software (e.g., an HTTP
>         server or SFTP server)
>      ~ has a partially-ordered user-defined namespace of revisions
>      ~ also has a separate partially-ordered history graph of revisions
>      ~ uses cryptographic hashing and signing to help establish the 
> integrity
>         and authentic authorship of revisions
>      ~ encourages the signing and distribution of explicitly reviewable
>         deltas between preceding and succeeding revisions

An idle thought: it might be a good idea to also think what
will differentiate Arch 2 from its competition.  There are a lot
of distributed version control systems with roughly the above
properties these days; everyone will want to know what makes Arch 2
different, so might as well work out a good answer up front.

In the business analogy, you need differentiating features to
compete successfully; in the allocation-of-volunteer-resources
game, it seems valuable to sit down and articulate the reasons
why it is better to start a new project from scratch instead of
contributing missing pieces to an existing project.  Plus, it'd
be just plain interesting to read :-).

Cheers,
-- Nathaniel






reply via email to

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