← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/rollup.txt

  • Committer: Aaron Bentley
  • Date: 2007-07-17 20:04:13 UTC
  • mto: (1551.19.24 Aaron's mergeable stuff)
  • mto: This revision was merged to the branch mainline in revision 2639.
  • Revision ID: abentley@panoramicfeedback.com-20070717200413-jpganazttxzryrx8
Deprecate RevisionTree.get_weave

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/rollup.txt
1
 
Roll-up changesets
2
 
******************
3
 
 
4
 
Sometimes it is useful to collapse changes; sometimes it is useful to
5
 
pull in patches while keeping their original identity.  So (uniquely?)
6
 
Bazaar-NG allows either option at the user's discretion.
7
 
 
8
 
I'm not completely sure yet how this should be controlled: should it
9
 
be an option at every stage, or should mergers generate roll-up
10
 
changesets?  I think possibly the second.
11
 
 
12
 
Rolled-up changesets can be represented as so::
13
 
 
14
 
  mbp, 2005-04-01
15
 
  import new quantum-computing feature
16
 
 
17
 
    jrh, 2005-03-02
18
 
    stub implementation for quantum computing
19
 
 
20
 
    jrh, 2005-03-03
21
 
    plus operator
22
 
    
23
 
    jrh, 2005-03-04
24
 
    regexps
25
 
 
26
 
    jrh, 2005-03-03
27
 
    fix bugs, ready to go
28
 
 
29
 
down to an arbitrary level of nesting.
30
 
    
31
 
When bringing changes into a branch, we have the choice of either
32
 
rolling them up into a single changeset or bringing them across
33
 
individually.  I'm not sure, but I think this may be best handled by
34
 
having two separate commands:
35
 
 
36
 
* *update* (or maybe *pull*) brings across revisions onto the current
37
 
  branch, adding them one-by-one into the revision history.  This can
38
 
  only be executed if the destination branch is a prefix of the source
39
 
  branch and therefore we know the patches will apply perfectly.
40
 
 
41
 
* *merge* pulls in one or more changes from another branch, and allows
42
 
   the user to edit the merged state or fix any conflicts.  These
43
 
   changes are then all marked as rolled-up by a new commit.  It is
44
 
   possible to look up those changes inside the commit, if the
45
 
   information is still accessible.
46
 
 
47
 
In this model, Arch is missing the first command: you cannot put
48
 
patches from one branch onto another -- and it would be hard to add
49
 
it, since the unique branch id is part of the name of the patch name.
50
 
 
51
 
Most other tools are missing the second: it is impossible to combine
52
 
changesets and therefore the total history of any branch can grow very
53
 
long; there is no way to make summaries within the tool itself.
54
 
 
55
 
People might also want to retrospectively zip up several changes
56
 
existing on a branch, but I think it may be better to make a new
57
 
branch from before the changes and pull them across onto that.
58
 
 
59
 
----
60
 
 
61
 
One interesting application of this is in maintaining the ``NEWS``
62
 
file present in many software distributions.  This summarizes the
63
 
changes to the software in each release at a very high user-visible
64
 
level.  Although this is very much version-control data it is not
65
 
normally known to the VC system, except as another versioned file.
66
 
 
67
 
One way to handle this is to have a *release* branch, where the commit
68
 
message for each release the NEWS notes for that release.