← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/rollup.txt

  • Committer: mbp at sourcefrog
  • Date: 2005-03-21 22:29:49 UTC
  • Revision ID: mbp@sourcefrog.net-20050321222949-232c2093a6eadd80
fixup doctest for new module structure

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.