← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/compared-opencm.txt

  • Committer: John Arbash Meinel
  • Date: 2007-03-15 22:35:35 UTC
  • mto: This revision was merged to the branch mainline in revision 2363.
  • Revision ID: john@arbash-meinel.com-20070315223535-d3d4964oe1hc8zhg
Add an overzealous test, for Unicode support of _iter_changes.
For both knowns and unknowns.
And include a basic, if suboptimal, fix.
I would rather defer the decoding until we've determined that we are going to return the tuple.
There is still something broken with added files, but I'll get to that.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/compared-opencm.txt
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.