Archipel principles

Archipel is build around a set of basic principles. This short page tries to list and explain them all.

Core principles :

• VERSION IS CONTENT: the version of a specific project configuration is identified by its content signature, this is called extensive versionning. It is however possible to create aliases to give names to particular versions.
• WHAT WAS COMMITED WON'T CHANGE: once something was commited to the repository, it can't be removed or modified. This obviously does not mean that the project that was commited won't change, but rather that the commited information will not be changed. This is called the monotonicity property of Archipel deltas (then you should understand why Monotone has this name).

Design principles :

• BE CLEAR: all Archipel commands are designed to give a clear, human-readable and program-parsable output to the user. The command names are choosen to be unambiguous.
• UNDERSTAND THE USER: Archipel has the notion of "tip". Whenever a command detects a particular configuration (eg: the user has not yet added files to its repository), it will print a tip telling what could be done next.
• GUESS AND ANALYSE: Archipel is not dumb, in the sense that it will try to guess what happened, and what changed. If you moved a file, Archipel will surely detect that you moved it, even if you changed it a little bit. All commands must do their best to automate the process, and do as much as they can.
• SIMPLICITY: Commands are not built with many options. Archipel design is use-case driven, so that common use cases are covered in the first place. The RDF database can later be queried to get more advanced usages.
• EXTENSIBILITY: The use of an RDF backend for SCM has the big advantage of allowing to easily produce many statistics and anlysis on the evolution of the software development. Archipel should be easily extended by using the data contained in the database.