/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/join-branches.txt

  • Committer: Martin Pool
  • Date: 2005-06-28 03:02:31 UTC
  • Revision ID: mbp@sourcefrog.net-20050628030231-d311e4ebcd467ef4
Merge John's import-speedup branch:

                                                                                         
  777 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:32 -0500
      revision-id: john@arbash-meinel.com-20050627032031-e82a50db3863b18e
      bzr selftest was not using the correct bzr

  776 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:22 -0500
      revision-id: john@arbash-meinel.com-20050627032021-c9f21fde989ddaee
      Add was using an old mutter

  775 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:02:33 -0500
      revision-id: john@arbash-meinel.com-20050627030233-9165cfe98fc63298
      Cleaned up to be less different

  774 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:54:53 -0500
      revision-id: john@arbash-meinel.com-20050627025452-4260d0e744edef43
      Allow BZR_PLUGIN_PATH='' to negate plugin loading.

  773 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:49:34 -0500
      revision-id: john@arbash-meinel.com-20050627024933-b7158f67b7b9eae5
      Finished the previous cleanup (allowing load_plugins to be called twice)

  772 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:45:08 -0500
      revision-id: john@arbash-meinel.com-20050627024508-723b1df510d196fc
      Work on making the tests pass. versioning.py is calling run_cmd directly, but plugins have been loaded.

  771 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:32:29 -0500
      revision-id: john@arbash-meinel.com-20050627023228-79972744d7c53e15
      Got it down a little bit more by removing import of tree and inventory.

  770 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:26:05 -0500
      revision-id: john@arbash-meinel.com-20050627022604-350b9773ef622f95
      Reducing the number of import from bzrlib/__init__.py and bzrlib/branch.py

  769 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:32:25 -0500
      revision-id: john@arbash-meinel.com-20050627013225-32dd044f10d23948
      Updated revision.py and xml.py to include SubElement.

  768 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:56 -0500
      revision-id: john@arbash-meinel.com-20050627010356-ee66919e1c377faf
      Minor typo

  767 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:13 -0500
      revision-id: john@arbash-meinel.com-20050627010312-40d024007eb85051
      Caching the import

  766 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:51:47 -0500
      revision-id: john@arbash-meinel.com-20050627005147-5281c99e48ed1834
      Created wrapper functions for lazy import of ElementTree

  765 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:46:37 -0500
      revision-id: john@arbash-meinel.com-20050627004636-bf432902004a94c5
      Removed all of the test imports of cElementTree

  764 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:43:59 -0500
      revision-id: john@arbash-meinel.com-20050627004358-d137fbe9570dd71b
      Trying to make bzr startup faster.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/join-branches.txt
 
1
****************
 
2
Joining branches
 
3
****************
 
4
 
 
5
(I think this is pretty brilliant. :-)
 
6
 
 
7
Branches diverge when people create more than one changeset following
 
8
on from a common ancestor::
 
9
 
 
10
  A:   0 ------- 1
 
11
  B:    \------- 2
 
12
 
 
13
We also allow branches to reunite.  This means that all the decisions
 
14
taken on multiple branches have been reconciled and unified into a
 
15
single successor::
 
16
 
 
17
  A: 0 ------- 1 ----- 3
 
18
      \               /
 
19
  B:   \------ 2 ----/
 
20
 
 
21
The predecessor of 3 is 1, in the sense that it was created on that
 
22
branch.  We could have created the exact same state as a successor to
 
23
2, and we can move that state onto branch 2 without any loss of
 
24
information.
 
25
 
 
26
(One thing we can do here is just delete B.  Because all of the work
 
27
there has been merged onto A, this will not lose anything.  We might
 
28
do this if the purpose of B has been achieved, such as completing a
 
29
feature or bug.  But if the work is still in progress, we might keep
 
30
it around.  It makes little difference whether we decide to do new
 
31
work in a branch called B or make a new one called C.)
 
32
 
 
33
That is to say that 3 can be perfectly (trivially) merged onto B,
 
34
with, say ``bzr push``, ``bzr pull`` or ``bzr update`` (whatever name
 
35
works best).  Perfectly merged means that we know there will be no
 
36
conflicts or need for manual intervention, and that we can just
 
37
directly store it without forming a roll-up changeset.
 
38
 
 
39
I think we might also like the choice of merging A onto B, rather than
 
40
pulling the changeset.  That causes a new changeset to be created on
 
41
B, noted as a successor of 2 and 3::
 
42
 
 
43
  A: 0 ------- 1 ----- 3 ------+
 
44
      \               /         \
 
45
  B:   \------ 2 ----+---------- 4
 
46
 
 
47
One complication is that 3 is probably stored in A's history as a
 
48
patch relative to 1; we can't just move this representation across.
 
49
Instead, we need to recalculate the delta from 2 to 3 and store that.
 
50
 
 
51
Despite that the delta is stored differently, the original signature
 
52
on 3 should still be valid.  So it must be a signature of the tree
 
53
state, not the diff.
 
54
 
 
55
Note from `Kernel Traffic discussion`__:
 
56
 
 
57
__ http://www.kerneltraffic.org/kernel-traffic/kt20030323_210.txt
 
58
 
 
59
    But anyway, what made Bitkeeper suck less is the real DAG
 
60
    structure.  Neither arch (http://arch.fifthvision.net/bin/view)
 
61
    nor subversion seem to have understood that and, as a result,
 
62
    don't and won't provide the same level of semantics. Zero hope for
 
63
    Linus to use them, ever. They're needed for any decently
 
64
    distributed development process.
 
65
 
 
66
This in turn suggests that possibly deltas should be stored separately
 
67
from the commits that create them.  Commits name points of
 
68
development; deltas describe how to get from one to the other.
 
69
 
 
70
The separation is nice in allowing us to send just a delta when
 
71
diffing trees or recording for undo.  We might want to compute many
 
72
deltas between different trees.
 
73
 
 
74
Is this a problem?  Does this ignore Tom's advice about the primacy of
 
75
storing changesets?
 
76
 
 
77
Splitting them is probably good, but then what manifest is stored in
 
78
changesets?  We don't want to store the manifest of the whole tree if
 
79
we can avoid it.  So I suppose the changeset just gives the hash of
 
80
the manifest, and the manifest then can be stored separately, possibly
 
81
delta-encoded.