1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
Taxonomy of version control systems
===================================
(ie a look at "cutting questions" that describe different design
approaches.)
History in working copy
-----------------------
Is history stored with working directory (bk, rcs, darcs), or
separately (cvs, baz)?
Storing in the working directory may be simpler in some respects;
it's one less concept people need to learn. On the other hand
people typically have more working copies than branches, and this
approach means having more copies of the history.
Naively, storing everything in the working copy can mean that you
keep multiple copies of the history, which would use a lot of disk,
or
Rewriting history
-----------------
Can you change recorded history (darcs); only do this through a
special mechanism (cvs, svn); or not do it at all?
Being absolutely able to reproduce any point in time reliably is
highly attractive. On the other hand, sometimes people commit
something (e.g. confidential information) that really should not be
recorded. And at a smaller level people might just commit the wrong
message.
Explicit edits
--------------
Can you edit any file in a working copy (cvs, tla) or must you
specially mark the before editing (rcs, bk)?
There are two reasons to mark files for editing. One is so that
people can be notified that a file is about to
Track history of patches
------------------------
Can you see how a patch got to its current destination? As far as I
know only arch can do this -- you can see what branches it
incorporates changes from. Well, kind of; not in an entirely
straightforward manner.
Collapsing patches
------------------
When patches from other people are integrated, can they be rolled up
into larger patches (arch) or do they retain their individual identity
(bk, darcs)?
|