Global shared repositories

[John Arbash Meinel]

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

Ville M. Vainio wrote:
| On Wed, Mar 12, 2008 at 3:18 PM, John Arbash Meinel
| <john at arbash-meinel.com> wrote:
|
|>  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).
|
| I suppose you can't get around this by grouping the packs by some
| magic cookie, e.g the hash from the first revision, creating a
| subgroup to search first and from which the pack would most likely be
| discovered?
|

There are things you could do, but you have to be careful not to introduce a
performance degradation when doing so. Using the hash from the first revision
seems like it would work, but then you have to always go back to the first
revision to find out the hash. Either that, or every revision descended from it
would somehow have to keep a reference that it came from this "first rev".

It also gets more complex when you start merging histories together. (There are
several plugins which started separately and then merged into bzr.dev, giving us
about 4 or 5 "first revisions".)

I personally use a shared repository locally that contains all of my plugins and
bzr code, and haven't had any noticeable issues.
I *don't* share it with my conversions of other projects which may be hundreds
of thousands of revisions.

|>  Probably the biggest reason not to do it is discoverability from a remote
|>  connection.
|
| But this is not an issue with bzr+ssh, right?

At the moment it still is. bzr+ssh has a lot of "smart" verbs for conversing
with another server, but it still falls back to some direct "virtual filesystem"
requests for things that haven't been implemented at a higher level.
We are trying to get away from them, though, to make the bzr:// protocol a more
complete abstraction. I expect will get there soon enough, but that isn't true yet.

|
|>  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.
|
| I'll look into that, but so far Alexander's suggestion of just putting
| the repo to c:\ will work for me. Perhaps that is something you could
| add to tutorial as well - it is not obvious from the beginners docs
| that shared repositories don't in any way require you to create an
| additional directory layer, or worse, have multiple shared
| repositories, one for each project.
|

Well, it is mentioned in passing here:
http://doc.bazaar-vcs.org/latest/en/tutorials/centralized_workflow.html

Though I've had quite a bit of criticism about putting something in ~ without
explaining it more. When I was writing that document I was trying to get people
bootstrapped up and running in an efficient manner without explaining every detail.

I know at the sprint one of the things we wanted to focus on making better was
getting people up and running with as few steps and in a "recommended" layout.
The problem with flexibility is that you then have to set it up.

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

iD8DBQFH1+8rJdeBCYSNAAMRAjaDAKCf7ge4w+HWOKQqsq/sCvqqLqb0uQCcD76/
4AfQQttrrAl/h4bOXimyctM=
=0FaX
-----END PGP SIGNATURE-----