~jteh/trac-bzr/newDeps

« back to all changes in this revision

Viewing changes to README

  • Committer: Martin von Gagern
  • Date: 2010-04-10 18:03:50 UTC
  • mfrom: (99.2.17 0.3)
  • Revision ID: martin.vgagern@gmx.net-20100410180350-thoyq8buakgsxq6t
merged 0.3.3 tag

Show diffs side-by-side

added added

removed removed

Lines of Context:
147
147
If you do not specify them, the following defaults will be used instead::
148
148
 
149
149
  [tracbzr]
150
 
  primary_branches = ,trunk
 
150
  primary_branches = trunk
 
151
  include_sideline_changes = True
151
152
 
152
153
primary_branches
153
154
................
167
168
 
168
169
.. _`glob patterns`: http://docs.python.org/library/fnmatch.html
169
170
 
 
171
include_sideline_changes
 
172
........................
 
173
This boolean flag selects whether or not sideline changes, i.e. those
 
174
denoted with dotted revision numbers, are included in the list of all
 
175
changes. This affects the output of the ``get_changesets`` method,
 
176
which in turn influences the events listed in the timeline view.
 
177
 
 
178
Note that there might be other plugins using that information as well,
 
179
so there might be other components beside the timeline view that get
 
180
affected by this setting.
 
181
 
 
182
Performance
 
183
===========
 
184
 
 
185
Some user-level operations are rather slow, because Trac's assumptions
 
186
about which repository operations are cheap vs expensive doesn't match
 
187
Bazaar's design.
 
188
 
 
189
Revision numbers
 
190
----------------
 
191
 
 
192
One of the problems is the mapping between revision identifiers and
 
193
revision numbers. The `Bazaar Revision Numbering Cache Plugin`__ might
 
194
help for this problem, although it's experimental and hasn't been
 
195
tested with trac-bzr extensively enough. Feedback welcome.
 
196
 
 
197
.. __: https://launchpad.net/bzr-revnocache
 
198
 
 
199
Last modifications
 
200
------------------
 
201
 
 
202
Another problem is that bzr has a different idea about the last
 
203
modification of a directory. In svn, any modifications of directory
 
204
contents is said to modify the dir as well. In bzr, only changes to
 
205
the set of files in a directory are counted.
 
206
 
 
207
Investigations are in progress about how to solve this problem,
 
208
probably through the use of caches.
 
209
 
170
210
Limitations
171
211
===========
172
212
 
182
222
namespace" and "branch namespace", it is impossible to view branches whose
183
223
directories are directly inside other branches' directories.
184
224
 
185
 
Speed issues
186
 
------------
187
 
Some user-level operations are rather slow, because Trac's assumptions
188
 
about which repository operations are cheap vs expensive doesn't match Bazaar's
189
 
design.  In particular, Bzr doesn't track "which revision last modified files
190
 
in this directory."  In theory, this can be solved by caching the results of 
191
 
expensive operations.
192
 
 
193
225
Revision order
194
226
--------------
195
227
If two changesets are not related to one another by some direct ancestry,