Global shared repositories

[John Arbash Meinel]

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

Ville M. Vainio wrote:
| On Wed, Mar 12, 2008 at 12:59 PM, Harald Meland
| <harald.meland at usit.uio.no> wrote:
|
|>  > Wouldn't it be handy to provide an environment variable (e.g.
|>  > BZR_SHARED_REP_DIR) to point to a shared repository that is global for
|>  > all the projects in the machine?
|>
|>  To expand somewhat on Alexander's reply: No, I don't think so.
|>
|>  Shared repositories are merely an space optimization, and they will
|>  only do any optimization if any branches shares some subset of
|>  revisions.
|>
|>  This means that there is little point in storing unrelated projects in
|>  the same shared repository.
|
| There would be, for people who only develop for, say, 2 or 3 different
| projects, and want more flexibility for their directory layout but
| still conserve space.
|
| Could the shared repository architecture be fixed so that there would
| be no file locking? I.e. only allow creation of new files, and once
| fully written all files would be read-only. I admit git is the only
| dvcs whose storage format I halfway understand (though I've never used
| it - I only read about it when it was the new cool thing from Linus,
| and it has probably changed a lot with time), so I am probably working
| with wrong assumptions...
|

There is actually fairly limited locking in pack repositories. We create new
packs in a staging area, rename them to their final location and name all
without taking out a lock.

The only time we need a lock is for a short period when we update the pack-name
list. (We do this because we don't assume you can listdir() the repository, and
because it gives atomicity, so that if you have renamed the .pack but not the
.iix it isn't "activated".)

Anyway, pack repositories were designed around scaling with lots of writers, so
I don't think that would be huge.

You would suffer a bit putting your 100 revision plugin next to your 10k
revision program. Just because some operations on the plugin are going to have
to search through the revisions for the program and discard them. Most of that
should only be in O(log(N)) space, not O(N). (In O(N) it would be 10,100 versus
100, while in O(log(N)) it is 4 versus 2, so 2x slower, not 100x).

Probably the biggest reason not to do it is discoverability from a remote
connection.

Also, someone else pointed out using a --no-trees repository with lightweight
checkouts, which allows you to keep your revision storage separate from your
working location. We certainly would like to make working in this mode easier.
(See the recent change to 'bzr switch foo' to allow it to figure out you
actually meant 'bzr switch /path/to/original/branch/../foo')

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH19hDJdeBCYSNAAMRAuQ0AKCySIGeNSOVMFTjWpXCSncWa9bmZgCeMrY/
UHPlJHlCG/yZBofqOcjd+fg=
=gqMr
-----END PGP SIGNATURE-----