Centralized storage in bzr
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
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
> ONE URL
> 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:
> 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