A few questions/potential issues in Bazaar-NG

[Matthieu Moy]

Hi again,

I'm considering a future migration from bazaar to bazaar-ng (that
won't be before October anyway), and have a few questions, or fear
about it. So far, I've only tried it quickly, and I only have a rough
idea of what it is.

"Migration" means potentially for me: Start using it, start porting
Xtla to it, and if "necessary", contribute to it.


Note: It's probably a good idea to answer on the Wiki, and post only
the URL while replying to this message, since some of those question
will become FAQs when people will consider the migration.


* "The archive is in the tree":

First: I don't like the "the archive is in the tree" paradigm. I like
to be able to have several trees (on several machines, typically). I
saw Aaron's post[1] and tend to agree.


* Archive names:

Archive names are something I like in GNU Arch. Here are a few reasons
for that:

 - It allows you to specify which branch you want to work on without
   having to remember the URL. Archive name never change, while URL
   sometimes do. If a URL changes, I just have to update the archive
   registry. Archive names Vs URL are a bit like DNS name Vs IP
   address: We could call machines by IP address, but it's much more
   conveinient to call them by name.

 - It allows me to keep easily a list of archive I sometimes merge
   to/from: "baz archives".

 - Bazaar's archive registration system allows me to deal nicely with
   multiply registered archives. Being able to type

     baz archives --names | xargs -n 1 baz archive-mirror

   to mirror _all_ the archive I've registered is just great. I'd like
   to have a similar way to do with bzr.

With the way bazaar handle archive names (you almost never _have_ to
use them, you _can_ use URL almost everywhere), it's little annoyance
for great benefit.

One interesting thing is to have an easy way to recognize if a string
represents an archive/branch/revision identifier, so that front-ends
can hyperlink them (Xtla does this in Gnus buffers in the development
version).

Adding a "bzr://" prefix may be a good idea for that (it also removes
the ambiguity between names and locations when necessary).


* Add only policy:

The add-only policy of GNU Arch in the archive is something nice.

 - It allows very simple and very efficient mirroring. An "ls" on both
   sides tells you what to mirror, and only the necessary data have to
   be uploaded.

 - It allows very efficient caching.

 - It makes incremental backups very efficient. Sysadmins like this.

I suppose it won't be doable with the Weave format. I just hope the
benefits will be larger that the loss of functionalities.


* The "dumb file server":

Being able to use almost any file server to host an arch archive is
simply great. Smart servers were not a problem at the time there was
almost only one RCS on the market (any free software hosting like
sourceforge gives you CVS), but can be a problem with today's
diversity.

Will Bazaar-NG be able to be hosted as simply as a GNU Arch archive?


* A way to classify branches:

I don't like the a/c--b--v namespace of tla. For unreleased,
mono-branch project, forcing me to put a --b--v is just stupid.
However, I like the idea of a collection of branches, and a way to
classify them. Commands like "abrowse" and "rbrowse" of Bazaar are
quite usefull IMO.

Some time ago, I argued in favor of a hierarchical namespace, to
classify branches like one classifies files in directories. Just like
the c--b--v thing, except that it could allow any level of nesting
(not exactly three), and would not force anything like GNU Arch forces
the --v component to contain only numbers and dots.

  http://lists.seyza.com/pipermail/gnu-arch-dev/2004-December/000421.html

This can be built "on top of bzr branches", and does not have to be in
the protocol itself (I mean: a branch does no necessarily need to know
which collection it belongs to), but it should be standardized (so, as
much as possible in the bzr itself) so that everybody use the same way
to classify collections of branches. However, sharing related data is
also a good thing.


* Inventory system and "unrecognized":

I also didn't like the junk/backup/precious classification in tla,
BUT, I like the "unrecognized" and "untagged-source" classification: I
have my editor's autosave file in "unrecognized" to prevent me from
committing with unsaved files in the way, and usually have
"untagged-source unrecognized" to force me to explicitely mark files
as precious.

Will Bazaar-NG have similar feature?


* Taglines:

Taglines do not only have advantages, but one of their qualities is
that it allows storing important inventory information in the tree, in
a way that do not disturb the users too much. It's used for Emacs to
track renames, although Emacs mostly use CVS as a revision control
system.


* Cheap branches:

With tla, if I don't put a cacherev on the tag, I can create a branch
for a project and submit a patch using very little disk space.
Currently, branching means copying the full repository. That's not
acceptable, for example, to submit a small patch to a large project
when you have a small quota on your webspace (I have 100Mb for
example).



I'll end with a few of the things I liked when trying Bazaar-NG:

* Plugin capabilities: I think this can be summarized by "The great
  plans of Tom with XL, but without a new language". Good for
  extensibility, good for per-project customization, and good for
  front-ends: For example, Xtla expects a specific format and set of
  informations in commands like "baz revisions". To port Xtla to bzr,
  I'm wondering if I should adapt Xtla to bzr output format, or
  provide a plugin to make bzr behave as Xtla expects when called
  through Xtla. BTW, this means it should be possible to provide a
  list of plugins to load from the command line.

* Progress bar: simple, but appreciable for a large download :-).

* No inode wasting (patch-log and inventory in tla 1.x).

* Possibility to have the archive inside the tree is nice (although I
  don't want to be forced to use this mechanism).


Thanks for the good work,

-- 
Matthieu