← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/cherry-picking.txt

  • Committer: Vincent Ladeuil
  • Date: 2007-05-25 17:12:52 UTC
  • mto: (2485.8.44 bzr.connection.sharing)
  • mto: This revision was merged to the branch mainline in revision 2646.
  • Revision ID: v.ladeuil+lp@free.fr-20070525171252-hsooebpkqtb3j6ef
Add test for cat and missing.

* bzrlib/tests/commands/__init__.py:
(test_suite): Add test_cat and test_missing.

* bzrlib/tests/commands/test_cat.py: 
New file.

* bzrlib/tests/commands/test_missing.py: 
New file.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/cherry-picking.txt
1
 
**************
2
 
Cherry picking
3
 
**************
4
 
 
5
 
Bazaar-NG allows you to try to 'cherry pick' changes from one branch
6
 
to another.  That is to say that you can merge across only the changes
7
 
from a particular commit, without getting anything else from that
8
 
branch.
9
 
 
10
 
However, because of dependencies in the source, it's not always very
11
 
practical to pick changes out of a widely-diverged branch.  The
12
 
general principle is that it's easier to keep things separate and
13
 
combine them later than to mix things up and try to separate them.
14
 
 
15
 
Therefore, we suggest using branches for each line of development that
16
 
might want to separately merge.  Create a branch for each major
17
 
feature; create branches for code that is ready to go upstream and for
18
 
code that is very experimental.  Branches are cheap.  As changes pass
19
 
through these branches they accumulate interesting metadata.
20
 
 
21
 
Design
22
 
------
23
 
 
24
 
There is little that a tool can do to help with merges once you start
25
 
cherry-picking changes; we need to rely on the merge tool detecting
26
 
that some changes have already been applied.
27
 
 
28
 
We should note that the changes have already come across, but I don't
29
 
see many places where that will be terribly helpful.
30
 
 
31
 
Sometimes a succession of cherry picks will be equivalent to merging
32
 
the whole history up to some point, in which case we can fall back to
33
 
a proper merge.
34
 
 
35
 
When choosing a merge ancestor I think knowing non-contiguous
36
 
cherry-picked changes will not help.
37
 
 
38
 
Cherry-picking is equivalent to putting the merge ancestor just before
39
 
the changeset(s) to be picked in.  So we can do this regardless of
40
 
whether we have the whole history of the tree.
41
 
 
42