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.
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.
12
Rolled-up changesets can be represented as so::
15
import new quantum-computing feature
18
stub implementation for quantum computing
29
down to an arbitrary level of nesting.
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:
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.
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.
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.
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.
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.
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.
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.
added
removed
doc/rollup.txt
