8
Not very stable; apparently inactive.
10
* Separated working copy & repository model.
12
* Files have long-lived identifiers.
14
* Files and revisions identified by the SHA-1 hash of their content
15
(as in monotone); explicitly makes it easier to be sure we have the
16
right one and prevents some tricks.
18
* Binding of objects to external names done on the client, so you can
19
version e.g. database objects, instead of files.
21
* Directories are inferred by having files that exist under them;
22
empty directories are a special case with an object of type DIR.
24
This is a bit ugly. I might rather have files given a name only
25
relative to their parent directory. So renaming a directory will
26
only update the entry for the directory, and everything will move
29
* Access-control rules about who can write to a central server.
31
* Their design is somewhat similar to ours and used a lot of disk
32
space -- enough to be a significant problem.
34
* Assigning human names to branches proved problematic -- i think this
35
is a good reason to rely on the filesystem/URL space, which people
36
already know how to manage and deal with.
added
removed
doc/compared-opencm.txt
