Re: Feedback on migration to bzr

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

Hi Matthew,

Thanks for the detailed feedback!

On Tue, Oct 30, 2007 at 10:43:02AM +0000, Matthew East wrote:
> Ok, so the migration would have been smoother if the following issues
> weren't there:

> 1. -sub-trees format issues. I used bzr-svn to import the repository,
> and discovered that this uses this format by default which is not
> supported by the default bzr shared repository. This means that:
> (a) When I tried to download the new branches into a normal shared
> repository I got an error message which I didn't understand - it
> didn't specify the problem or reference any documentation at all.
> (b) I was a little concerned initially when I found out that we were
> using experimental functionality without being informed of this by the
> relevant web pages in advance - subsequently I was reassured that the
> format is unlikely to create issues for us.
> (c) People wishing to download our branches into existing shared
> repositories they have cannot do so.

> Obviously I don't have the technical background to express an opinion
> on whether this format should be used or not, but there definitely
> should be a "bzr-wide" policy about this, rather than have bzr-svn use
> it by default, and bzr not.
This has come up a couple of other times before. How likely is it that
subtrees are going to land soon? If they are still some time off,
would it perhaps be possible to have a data format that can
store rich roots but not subtrees and as such doesn't have to be
marked experimental?

> = Other feedback =

> I like bzr a lot. However, it could be improved with:

> * Better error messages - the python traceback messages are pretty
> hard to understand and generally don't give any hints to the beginner
> what the actual problem is.
During "regular" use you should never see any python traceback;
tracebacks are usually the indication of a bug in either Bazaar or one
of the plugins loaded. Can you perhaps give an example of such a
backtrace?

> * Better progress reporting - the progress bar is pretty inaccurate
> when pushing and downloading branches. Without doing any detailed
> analysis, we've tended to find that it starts at about 40%, stays
> there for most of the download time, then skips to 100% pretty
> quickly. Also, it's hard to understand what's going on with the 1/4
> message on the right hand side of the progress bar. I haven't delved
> into the bug list to see what is already there on this issue, but a
> simple and single progress bar with an accurate percentage would be
> helpful.
Yeah, that has been my observation as well. I wouldn't actually mind
seeing three or four different progress indicators, one for each
phase.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer@xxxxxxxxx> - http://jelmer.vernstok.nl/
 12:04:33 up 4 days, 15:16,  8 users,  load average: 0.32, 0.88, 0.84