Centralized storage in bzr

Martin Pool mbp at sourcefrog.net
Tue Jun 14 09:14:59 BST 2005

On 13 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Hi all,
> Here are my thoughts on how we could support centralization in bzr
> without losing most of the advantages of keeping everything in the
> working directory.
> So bzr works like Darcs, and in some ways, that's great.  Administration
> is pretty simple, and the idea of "All my stuff is in this directory" is
> pretty easy to grasp.
> But there are also advantages to centralized storage: speed and size.
> When pulling a branch, you only need to download stored entities that
> aren't already in the centralized store.  So if I had a branch of bzr,
> and you'd already downloaded Martin's branch, you'd only need to
> download those revisions that I'd committed.  And of course, you only
> need one copy of each stored entity, instead of duplicating them as we
> currently do.
> There's also the administration advantage that you only need to back up
> one location that is unlikely to change.

> So if optional centralized storage is a good idea, how do we hold on to
> as many of the advantages of independent branches as we can?
> 1. a branch can be specified with one url
> 2. working trees can be moved around easily with mv
> 3. working trees can be seamlessly branched using cp
> 4. branches do not use filesystem properties that NTFS lacks

The other property I'd add is that it should be hard to unexpectedly
lose information.

At the moment I have in mind a perhaps more conservative approach of a
search path for objects.

So when branching:

  bzr branch --search ./bzr.dev http://foo/bar/

Any revisions, inventories or texts that are in bzr.dev will be used
directly from there rather than copied from the remote server.  These
pathes are stored into .bzr/search-branches for later use. 

These other branches are strictly read-only, used just as a local
lookaside cache.

> It's tempting to say "let's just centralize the stores, and keep
> everything else where it already is."  If we did that, presumably we'd
> keep some data about where to find the stores in the branch.  For remote
> users, this can be a problem.  We'd need to convert the filesystem path
> to a URL.  This could be difficult, or could be impossible, if the
> central store was not remotely accessible.
> I think it makes more sense for all branch data (but no working tree
> data) to be stored centrally.  So you have:
> $ANYPATH/stores/revisions
> $ANYPATH/stores/inventories
> $ANYPATH/stores/file-contents
> $ANYPATH/branches/branch1
> $ANYPATH/branches/branch2
> $ANYPATH/branches/branch3
> So users just have to ensure that $ANYPATH is remotely accessible, and
> bzr clients just need to look at $ANYPATH/branches/branch3/../../stores
> to get the storage.

So do you mean each working directory would include a file containing
ANYPATH, and history wouldn't normally be stored in the working

This seems a lot like the idea of "bound branches" -- branches whose
history is stored elsewhere, possibly in a place shared between
multiple working copies.  I think that will be good for some
situations but I don't think it should be the default.


More information about the bazaar mailing list