← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/taxonomy.txt

  • Committer: Aaron Bentley
  • Date: 2007-06-22 22:19:13 UTC
  • mto: (2520.5.2 bzr.mpbundle)
  • mto: This revision was merged to the branch mainline in revision 2631.
  • Revision ID: abentley@panoramicfeedback.com-20070622221913-mcjioqruw8rhgnd8
Improve locking in _BaseMergeDirective.from_object

Show diffs side-by-side

added added

removed removed

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