|
6
by mbp at sourcefrog
import all docs from arch |
1 |
****************** |
2 |
Compared to OpenCM |
|
3 |
****************** |
|
4 |
||
5 |
http://opencm.org/ |
|
6 |
||
7 |
||
8 |
Not very stable; apparently inactive. |
|
9 |
||
10 |
* Separated working copy & repository model. |
|
11 |
||
12 |
* Files have long-lived identifiers. |
|
13 |
||
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. |
|
17 |
||
18 |
* Binding of objects to external names done on the client, so you can |
|
19 |
version e.g. database objects, instead of files. |
|
20 |
||
21 |
* Directories are inferred by having files that exist under them; |
|
22 |
empty directories are a special case with an object of type DIR. |
|
23 |
||
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 |
|
27 |
with it. |
|
28 |
||
29 |
* Access-control rules about who can write to a central server. |
|
30 |
||
31 |
* Their design is somewhat similar to ours and used a lot of disk |
|
32 |
space -- enough to be a significant problem. |
|
33 |
||
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. |