observation about trac+bzr and bzr smart server with big repo

[Robert Collins]

On Tue, 2008-10-14 at 10:17 +0100, Russel Winder wrote:
> 
> 
> 
> On Tue, 2008-10-14 at 19:50 +1100, Robert Collins wrote:
> 
> > The --development2 format in bzr.dev would likely have dealt with
> your
> > big repo much better; basically the indices in the pack-0.92 and 1.6
> > formats are much slower than development2 (and anything getting
> added
> > these days).
> 
> Just a quick note of informal feedback:  The plethora of different
> store
> formats in Bazaar appears to be a big turnoff for people coming to
> DVCS.
> They see Mercurial and Git just getting on with it, whereas Bazaar
> offers an array of different formats, none of which mean anything
> useful
> to them (and not just new users either, I get confused by the
> selection
> of formats available).

There is a weird perception thing going on here. I see hg struggling
massively with Window support, because they are not fixing the
fundamental issues with their repository. When people stop fixing the
root causes of bugs in software *thats* when cruft occurs. It's a rare
designer that can get the final design correct first time around (and I
don't know *any* open source VCS system that has managed that).

I appreciate that bzr has had a few formats, and don't want to add
things that will confuse users for the sake of confusing users ...
however the perception here is also skewed by a certain misperception
regarding git and hg here: By a loose count git has had at least three
format changes where newer clients generate data older clients cannot
cope with the repo (packs and subtrees); possibly more than three (I
seem to recall an index change to add a root for very large packs). hg
likewise has had a number (again, I don't know the exact number, but 3
or more by a loose estimate).

bzr is very clear about our formats, and careful to allow newer clients
to write only data that old clients can read. We've had (since 1.0)
precisely 1 family of new formats added.

Generally users should not need to worry about the formats [with one big
glaring exception(*)]. They are essentially internal except where a new
feature requires a semantic change (and thus a new format).

Our format support brings serious benefits though - unlike svn we
support old versions of working trees (svn also has had numerous format
changes (bdbfs, fsfs, the 1.5 metadata change, at a minimum), and unlike
bzr it force-updates checkouts. Run svn on NFS, and if one client uses
svn 1.5 on an existing checkout, *everyone* *must* update to 1.5).
Indeed, bzr-loom, bzr-git, bzr-svn, bzr-hg all depend on the format
pluggability to operate.

(*)
Lastly, that big glaring exception is rich root support; which 'we' want
to get on by default real-soon-now. Its not a no-brainer, but it will
signficicantly shrink the number of formats that need to be listed when
we do improve bzr's disk layout in the future. And I certainly don't
intend to stop improving things anytime soon.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081014/d8871384/attachment.pgp