|
6
by mbp at sourcefrog
import all docs from arch |
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. |