← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/taxonomy.txt

  • Committer: John Arbash Meinel
  • Date: 2005-11-18 21:01:53 UTC
  • mto: (1185.50.19 bzr-jam-integration)
  • mto: This revision was merged to the branch mainline in revision 1512.
  • Revision ID: john@arbash-meinel.com-20051118210153-88fd1a200bdd872c
Updating transport test, to handle NoSuchFile if a bogus url accidentally resolves.

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