
! The Principles Behind the Design of Arch

Not that any of these can be precisely defined, but for reference, the
design of arch should be guided by these principles:


* Simplicity

  Arch should have a _small_ set of essential functionality that
  provides a basis set for everything revision-control-related.
  Each command should do one thing well.

  Everything else besides this essential functionality should be 
  built and maintained separately, as extensions to arch or layers
  built on top of arch.


* Clarity

  It should be possible to explain, precisely and completely, what
  each command does.  If a command has lots of special cases and 
  exceptions, or if it isn't clear how it will handle some inputs,
  then something has gone wrong.


* Smallness

  The implementation should remain small.  If anything, it should be
  smaller than it currently is.  Not much additional core
  functionality is needed, and some of what is currently there can 
  be factored out.


* Speed

  Arch should be very fast -- faster than it is now.  (There are two
  bottlenecks: the speed of mkpatch/dopatch, and the limitations that
  come from having dumb servers.  See PatchHandlingSpeedups and
  SmartServers).

  One good goal is for arch to be able to handle the Linux kernel
  well.  I have some other goals to, though I need to get permission
  before publishing them.


* Precision

  A complete set of specs are needed such that an arch-compatible
  re-implementation can be built just from those specs.  We need
  a set of correctness tests that agree with the specs and that 
  are implementation independent.


* Consonance

  Arch should work well with adjacent tools in the sw-eng. toolbox.

<<<
>>>



%%% tag: Tom Lord Wed May  1 23:20:14 2002 (ArchRevCtl.d/ArchPrinciples)
%%%
