Some feedback on Trac-Bzr 0.3

[Martin von Gagern]

Hi Alexander!

Thanks for pointing out this post in a private e-mail, as I indeed don't
follow this list too closely and will easily miss list postings
regarding trac-bzr.

On 19.02.2010 11:01, Alexander Belchenko wrote:
> Many thanks for releasing Trac-Bzr 0.3. I've just installed it on my
> Trac instance and it seems work, excluding empty branches case.
> It works OK with bzr 2.1.0 too.

The empty branches should work by now as well; I've released 0.3.1
addressing that issue. If not, let me know.

> But I want to note that Trac-Bzr is unusable slow for some sort of
> operations.

I know there are quite a number of these cases. I have some good ideas
about how to implement caching for 0.4. There is a blueprint for it at
https://blueprints.launchpad.net/trac-bzr/+spec/caching but most ideas
are in my head and a few lines of incomplete code so far.

> Especially to get log on the file I need to wait several
> minutes. Even slower it processes request to see changeset. My branches
> are not so big as Emacs or Linux kernel tree, but the effect is just
> depressed. I don't know is it possible to improve something there. Maybe
> our beloved core devs can help with hints/suggestions here. But the same
> operations invoked in command line works much faster.

For some of these things, I have a rough idea what's causing them to be
so slow. For most of the points you notice, however, I don't know what's
causing it. If you want to, you can file bug reports for all these cases
and tag them with the performance keyword. I'm not sure if I could do
anything about it before 0.4, and by then I'd probably first ask you to
check if the issues persist.

If you want to help debugging, I could push a branch providing a
profiling decorator which you could sprincle around the code to see
where Trac spends its time. Any insights here might help make the right
choices for 0.4 development. Any methods working with ancestry instead
of history are likely candidates for performance bottlenecks. And if no
trac-bzr code is spending huge amounts of time, a performance problem in
Trac itself might be possible as well. Someone suggested as much for the
diffing done when listing changesets.

> Although I should note that Timeline with Repository checkins option
> turned on is much faster now. Thanks!

I guess that's the get_changesets implementation, especially its cutoff
feature which limits the generated history.

> But today for me Trac-Bzr integration is useful only as branch browser
> to see paths to my branches on the server, and no more. :-(

I've got plans to make things better. I have caching in mind, and a
cleaner design for large portions, and improved multirepo handling, and
a qlog-like graph browser, and a lot of other nice features. But I have
only very little free time to invest into this project, so unless some
company wants to sponsor my work, I guess it will be slow going.

> Thanks for your work,
> Alexander

Thanks for your feedback,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100220/c4c3d4e1/attachment.pgp