Roadmap for Bazaar...

[John Szakmeister]

It's been quiet on the list lately, so I figured I'd ask a question
that has been lurking in the back of my mind for a while.  What's the
goal for Bazaar over the next couple of releases?  And while I'm
asking, what's the real aim of Bazaar?  Are you looking to be as
wide-spread as SVN?  To appeal to similar kinds of people?  Just
developers?  I ask, because it kind of sets the tone for how easy
Bazaar needs to be to get started and scale with its intended
audience.

Just to offer some feedback, here are the pain points I keep running into:
  * The authentication story is still a bit lacking.  It'd be nice for
Bazaar to offer the ability to automatically store credentials in
gnome-keyring, kde's equivalent, or encrypt the password under
Windows.  Folks authenticating against http and LDAP, or Active
Directory, have the problem that passwords change often.  Bazaar
doesn't make it easy to update them. :-(

  * Co-located branches in the native Bazaar.  Trying to explain to
newbie that they must branch to somewhere else on their disk is a
pain.  As easy as the concept seems, git's story is much nicer.  Plus
it scales.  Git's story remains the same as you have more branches of
the project.  With Bazaar, I have to explain that a shared repo is
probably what you want, and then I have to explain more internals than
I care to.  It's doubly painful, when you realize that now you have to
copy around settings for the IDE, and set up the project again.  The
fact that Bazaar doesn't work out of the box for them is unfortunate.
The installers help, but don't do much for our Linux crew, who
currently istalls from source.

  * Nested trees.  Lots of folks have big projects, and they're
currently using SVN's externals (which I loathe).  Unfortunately,
without this feature, folks don't know a good way to organize their
tree.  Oh, and somewhat related to this, I think svn:revno should pick
the most recent version of a branch if it wasn't modified in revno...
just like SVN does.  Otherwise, nested trees aren't as useful against
SVN repositories (about half the ones I work against would be broken).

  * Better hosting.  The smart-server HTTP hosting story is still
broken.  You have to use bzr+http:// urls, otherwise bzr jumps back to
plain http access in a number of areas.  A bug has been filed for
this, but not much has happened on it.

  * Revision ids that are easier to reference than Bazaar's revision
ids.  An issue that I've been running into a lot with newbies is the
fact that revision numbers can change easily.  Bazaar won't think
twice about re-ordering the mainline, especially if your pushing back
to a branch, and you've merged the tip of that branch in it already:
   bzr branch <main> <work>
   # Hack, hack on work
   bzr merge :parent # into <work>
   bzr push :parent

It'd be nice if Bazaar didn't allow that push by default (something
that I think you guys have talked about).  But if you aren't going to
do that, then I think it's a good idea to have revision ids that you
can refer to easily that don't change.  You have the latter, but they
aren't easy to refer to.

I hope you don't mind the criticism.  I've been doing a lot of
educating lately (writing a class for Bazaar and teaching folks in our
company) and thought I'd share the pain points.  We like Bazaar, and
especially the QBzr plugin, but feel it could be easier.

Thanks for listening!

-John