/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/compared-opencm.txt

  • Committer: Martin Pool
  • Date: 2005-08-24 08:59:32 UTC
  • Revision ID: mbp@sourcefrog.net-20050824085932-c61f1f1f1c930e13
- Add a simple UIFactory 

  The idea of this is to let a client of bzrlib set some 
  policy about how output is displayed.

  In this revision all that's done is that progress bars
  are constructed by a policy established by the application
  rather than being randomly constructed in the library 
  or passed down the calls.  This avoids progress bars
  popping up while running the test suite and cleans up
  some code.

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.