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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
*******************************
Bazaar Barcelona Sprint 2009-05
*******************************
* nested trees agreement [robert]
* new UI model - colocated branches etc - from principles [robert]
* looms - future? new format?
* shallow branches?
* better modelling of bug-branch linking in bzr
* new bundle format - and cross-group compression?
* finishing 2.0 - for July!
* brisbane-core stacking
* 3.0 work
* get rid of file locks
* bzr-gtk all-in-one Win installer
* productivity - process improvement - esp bugs and reviews
* planning 2.0 upgrades and transition on Launchpad
* general loggerhead design work
* preforking bzr on the server
* tortoise bzr - choosing gtk vs qbzr, future maintenance?
* making it easier to work with
* not well maintained
* unifying bzr-gtk and qbzr?
* launchpadlib as a soft dependency (python WSDL client)
* parallel imports and path tokens!!
* bzr book and documentation
* bug 336749 "ghost left-hand parent"
* improved foreign branch support (connected to parallel imports)
* adding bzr support to gitorious
* easier setup of simple bzr hosting
* packaging and availability on all platforms
* full test suite passing everywhere - cross-platform buildbot?
* batteries included and checking tests of plugins
* inventory-delta stuff for streaming across formats?
* easier resolution of conflicts for less-knowledgeable users
* more interactive commands?
* inter-format stacking
* format and upgrade strategy - constraints on adding new formats etc
Notes
*****
Nested trees
------------
* file-id uniqueness constraint and supporting copies
* performance concerns
* naming of branches
* model of compositetree
* lean waste: work done and not shipped yet
* "just stop the line, don't feel bad about it"
Process changes
---------------
* Get around the right-vs-now dilemma?
* Focus on avoiding waste?
* Development format can be more unstable and experimental?
Should be easier to do things that might be wrong.
* Unclear how we go from production to development.
* How to have something for user testing that's not super high cost or
risk.
* Require design documents? Enhancement proposals, before starting?
* Not a replacement for code review, and not a guarantee it will get through code review.
* Master index of these things.
UI changes
----------
* Should be easily predictable whether a command will be expensive or not,
eg branch.
* Should be an easy way to deal with errors, eg when something is locked.
eg stacking wrong, bad formats, ...
* Should be able to imagine making it scalable to large things.
Talking about one feature per branch.
People get into trouble with bzr add/bzr commit.
Do people want specific branches? Are branches semantic?
Emergent behaviour should be good by default.
UI Redesign
-----------
* There are edge cases in our current model (e.g. lightweight checkouts of
bound branches), that we'd be happy with losing to provide a much stronger
experience.
* Rob states that adding complexity ...
* Let's flip a coin about URL separator in Bazaar branches
* Colocated branches as currently implemented is slow -- finding branches is
slow.
* Scale of #branches colocated needs to be decided
* Features for managing the colocated branches needs to be considered
* Grouping
* Tags
* Managing branches is an interesting problem. Current approach is nice in some ways, moving branches between
directories, But there are some other issues.
* Possibly question the assumptions in our current Branch / Tree / Repository
model.
* Git has a reflog, maybe we should have something like that.
* Users bump into problems when creating files, then committing them when not
adding.
Why
---
* Users are finding what we've got confusing system that's often less
appealing than Git, particularly when dealing with multiple branches
* Compiled applications
* IDEs that store abspath
* Slow network performance by default
* Hard to discover features
Principles
----------
* Users should know in advance if a command is going to be slow or fast
* Always give the user a way out of any error that we give them
* UI should in some ways be an emergent function of the system
* Don't expect perfect users. Be tolerant of mistakes
* Scales well to a million branches with a million revisions of a million
files
* Encourage good development practices
* Make it hard to make stupid mistakes
* A small number of clear concepts
Rio or bencode representation of revision metadata
--------------------------------------------------
* Either one gets away from some infelicities of xml, such as not being
binary-safe
* igc found rio serializer somewhat faster than xml
* bencode arguably somewhat more robust
* question of sometimes wanting to read only some properties
|