/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/rollup.txt

  • Committer: Martin Pool
  • Date: 2005-06-28 03:02:31 UTC
  • Revision ID: mbp@sourcefrog.net-20050628030231-d311e4ebcd467ef4
Merge John's import-speedup branch:

                                                                                         
  777 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:32 -0500
      revision-id: john@arbash-meinel.com-20050627032031-e82a50db3863b18e
      bzr selftest was not using the correct bzr

  776 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:22 -0500
      revision-id: john@arbash-meinel.com-20050627032021-c9f21fde989ddaee
      Add was using an old mutter

  775 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:02:33 -0500
      revision-id: john@arbash-meinel.com-20050627030233-9165cfe98fc63298
      Cleaned up to be less different

  774 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:54:53 -0500
      revision-id: john@arbash-meinel.com-20050627025452-4260d0e744edef43
      Allow BZR_PLUGIN_PATH='' to negate plugin loading.

  773 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:49:34 -0500
      revision-id: john@arbash-meinel.com-20050627024933-b7158f67b7b9eae5
      Finished the previous cleanup (allowing load_plugins to be called twice)

  772 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:45:08 -0500
      revision-id: john@arbash-meinel.com-20050627024508-723b1df510d196fc
      Work on making the tests pass. versioning.py is calling run_cmd directly, but plugins have been loaded.

  771 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:32:29 -0500
      revision-id: john@arbash-meinel.com-20050627023228-79972744d7c53e15
      Got it down a little bit more by removing import of tree and inventory.

  770 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:26:05 -0500
      revision-id: john@arbash-meinel.com-20050627022604-350b9773ef622f95
      Reducing the number of import from bzrlib/__init__.py and bzrlib/branch.py

  769 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:32:25 -0500
      revision-id: john@arbash-meinel.com-20050627013225-32dd044f10d23948
      Updated revision.py and xml.py to include SubElement.

  768 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:56 -0500
      revision-id: john@arbash-meinel.com-20050627010356-ee66919e1c377faf
      Minor typo

  767 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:13 -0500
      revision-id: john@arbash-meinel.com-20050627010312-40d024007eb85051
      Caching the import

  766 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:51:47 -0500
      revision-id: john@arbash-meinel.com-20050627005147-5281c99e48ed1834
      Created wrapper functions for lazy import of ElementTree

  765 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:46:37 -0500
      revision-id: john@arbash-meinel.com-20050627004636-bf432902004a94c5
      Removed all of the test imports of cElementTree

  764 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:43:59 -0500
      revision-id: john@arbash-meinel.com-20050627004358-d137fbe9570dd71b
      Trying to make bzr startup faster.

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.