/breezy-loom/trunk

To get this branch, use:
bzr branch https://code.breezy-vcs.org/breezy-loom/trunk
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
loom format2 - based on branch6

commands to make:
 - l-commit: 'record' has been written as a primitive to record a new patch.
   ensures nick in loom, record tree into loom branch for nick, commit into the
   branch of the nick in the loom and pull that onto the tree, with
   --overwrite.
 - push - pushes loom, checks for loom tip correctness.
 - eject - remove a entry from the loom, and merge it out of the next one up.
 - unloomify - remove the loom branch reference.
 - revert  loom-merge
 - diff
 - status

teach launchpad about looms.
this fixes the first-push-problem of new branches with bzr for package management because it means one loom per package, not one branch per change.

Create a 'bzr help loom' command to give a good overview.

'bzr check' on a loom branch should check the loom is consistent with the branch.

rename threads to 'warps' - the threads held under tension by the loom.
Modelled on a ground loom with the supports to the left and right - old and new
- of the weaver.


possibly: override the nick property on the loom to do a push/pop etc as needed.

teach up-thread to use '<<< THREADNAME' rather than '<<< MERGE-SOURCE'

cut-warp ? eject - whatever - should refuse to eject the last one, or perhaps
should unloom at that point.

push/branch should not set an explicit nick if there are no threads in the loom

normal branch.pull (loom) gets current warp. (default contract ensures this)
loom.pull(normal branch) pulls into current warp. (default contract ensures this)
loom.pull(loom) starts at the lowest warp and pulls matching warps until
a conflict occurs. Optimised by pulling the union of:
 * current rh-tip and thread rev ids.

LoomTreeDecorator has too much UI code - it raises the wrong exceptions and
does note calls.

- make merge do something sane...
        XXX: Currently we do not handle any
        new warps in the source: they are skipped over
        deleted warps in this loom: they are treated as new warps in the source
        renamed warps: threated as new warps in the source.
        deleted warps in the source: they remain in this loom, though the
        content removals in the remote loom which have been propogated are
        propogated here.
- do merge of a loom logic.
- teach uncommit to uncommit the loom *IF appropriate*.
- make pull and push print something sensible rather than revisions pushed.
  - perhaps a 'change descrption' object that the pull method can return.
- make pull BRANCH#warp work to grab one element of a warp. 
  In a warp this should attempt to pull the lower warp elements first?, then 
  just pull the warp into this warp. A reason to grab the lower warp
  elements is to preserve the right delta between the lower warp elements. A
  reason not to, is that the 3-way merge will do the right thing anyway, and
  there is no need to require my warp to have all the subcomponents of yours
  when I just want the resulting patch as a component of my warp. If your 
  baseline warp is ahead of mine, I'll just get no-op updates.
- record loom with merges to record a merge
- record loom with conflicts to refuce to commit
- pull into a 'new loom' without error or warning from an existing loom.
- ' merge into a loom to create combined loom.'
- include basis and parent revids in current-loom for each warp.
- revert loom falls back to the next lower thread.
- factor our LoomParsing etc into a helper class.
- test for revert -thread when the thread stays present.
- revert thread puts you on the next up remaining thread when the current thread goes awol if there are up-threads to go to.
- want to be able to say 'here is a partial loom, now change it'
- want to be able to say 'here is a loom stream, read it'
- want to be able to say 'here are some threads, write a loom'
- want to be able to say 'here are some parents, write a current-loom'
- want to be able to say 'here is a current-loom, want to update it.'
- cache loom state objects in the transaction entity cache [probably a bad idea RBC 20080120]
- TODO: a merge of a no-change commit should be allowed?
- disallow pull with a modified current loom, or do a merge during pull.
- raise clear errors on corrupt loom-state.
- lazy use of LoomStateReader in LoomState?
- LoomState to enforce valid revisions in set_parents etc - no \n or whitespace.
- bug: up-thread incorrectly sets pending merge when the thread is already merged.
- UI question - show a marker on all 'applied' threads. i.e. a 'empire state besides the threads list'.
- revert-loom thread did not reset branch status correctly in the tree.
- bug: up-thread with an out of date tree fails with BzrCommandError not bound.
- bzr loomify && bzr revert-loom should preserve revision history.
- nice errors for loom branch commands on non-loom branches.
- better offset management for adjust_current_index.
- nice 'split diff into branches' tool
- diff -r thread: to diff against lower thread (using -ancestry logic) (-r
  thread: seems best placed to report on the threads actual revision id; this
  TODO either means changing 'diff's defaults, adding a flag to diff, or using
  a different revspec prefix; or something like that.)
- export-patch to export the diff from this thread to the lower thread (using -ancestry logic) to a file named as the warp is named. (what about / ?)
- during up-thread, if we could pull or if there is no diff, then the thread has been merged, offer to remove it. (Currently suggests to remove it).
- loom to have the same 'tree root id' as its branches, to allow nested looms by reference. EEK!.
- show-loom to allow -r -1.
- combine-thread to warn if the thread being combined has changes not present in the one below it. I.e. by ancestry, or by doing a merge and recording differences. For bonus points, do the merge, but record the lower thread as the last-revision in the tree still, and set no pending-merges. This preserves the difference whilst still combining the threads.
- revert-thread on a combined or ejected thread should do something reasonable.
- branch.remove_thread needs testing for cases: no such thread, thread is the current thread.
- record_thread should allow a record to happen even if the thread is not changed IF the parents list is different, not counting None entries.
- pull should not throwaway local commits - they should get preserved in some manner. i.e. if the revision id in last-loom != that in the basis loom, it should become a parent in last-loom. This implies a variable length list of parents for every line - which is catered for.
- remove thunks to NULL_REVISION to be EMPTY_REVISION once bzrlib supports that.
- test revision spec with non loom branches.
- print a message 'pushing thread to branch' when doing a push/pull from a normal branch.
- fetch should examine *every* fetched loom revision and fetch the contents
  therein as well, to support uncommit between record calls.
- combine-thread should de-dup penmding merges (use case: up-thread finds a fully merged thread so there are pending merges but no diff between threads; this is when combine-thread is often called).
- support tags on push/pull in looms
- perhaps bzr send should send the whole loom ? (e.g. as a patch bomb - a series of patches?)