Centralized Storage, round 2

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,

Rob Weir has done some work on centralized storage for bzr, which I
appreciate.  Unfortunately, he wasn't aware of my earlier posting,
despite it being referred to on the CentralizedStorage wiki page.
(it's here:
http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/1352)
When I pointed this out, Robert Collins opined that Weir's work achieved
much the same benefit that my approach would, but was much simpler.  I
disagree, so it's time for Round 2.

As I understand it, Weir's approach is to move the text store, inventory
store and revision store to a central location.  The branch contains a
pointer to the central store.  The remainder of the branch data is
untouched.

My approach involved moving all the branch data into central storage--
not just the stores, but also the revision history, and other branch
data.  Working tree data, such as pending-merges, would remain in the
working tree.

Storing all the branch data centrally means that there is a single
location in which all a user's data is stored.  This has advantages for:
- - publication (just point your DocumentRoot at one directory)
- - mirroring and backups
- - interactive exploration

As well, it means that working trees can be deleted without destroying
the branch data.

Finally, they retain the ability for remote users to download a branch
using just one location.

If the branch data is stored in the working tree, both the centralized
store and the working tree must be publicly accessible.  The working
tree must refer to the centralized store using a relative path, so that
the same path is applicable locally and remotely.

Using a relative path imposes restrictions on moving the working tree,
because some moves will change the meaning of a relative path.  For
example:

If the central store is at ~/central, and the branch is at
~/programming/bzrtools, then the relative path will be ../central.  mv
~/programming/bzrtools bzrtools will cause the relative path to refer to
~/../central.

Keeping the branch data in the working tree also means that if you want
to publish the branches, you must work in a directory that is under the
DocumentRoot of your web server.

It also makes backups and mirroring harder, as your branches are no
longer likely to be in the same place.

And of course, deleting working trees destroys the branch history.

My proposal is not flawless.  The main problem David Allouche found with
it was that by default, it used the branch directory name as a unique
name.  I had assumed that anyone who needed multiple branches with the
same directory name would have to set their unique branch name manually.
 This could be problematic with configs.  (or maybe not; cm build-config
- --branch-suffix "-newthing")

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJJKe0F+nu1YWqI0RAkj1AJ9sA5tzPB7Wlfn5S7YaeyhKmjQmMQCfT7Cz
zUByoPFLJKPkil1StuSCL4Y=
=TQxg
-----END PGP SIGNATURE-----