Centralized Storage idea (Was: Centralized Storage)

[Jan Hudec]

On Mon, Sep 12, 2005 at 11:27:32 -0400, Aaron Bentley wrote:
> > I have several concerns about your proposal as it stands :
> > 
> > - it introduces a mandatory namespace to use this central store. this
> > hurts the user by forcing them to resolve conflicts when they have ended
> > up with duplicates of a branch
> > - It introduces an archive-like concept to bzr, which is another thing
> > for folk to learn and understand (rweirs branch does this too, but to a
> > lesser degree, as the container doesn't have branches in it, just
> > revisions).
> 
> No such thing as a little bit pregnant.  Either you have this additional
> concept or you don't.  If we're going to have it at all, we should have
> the most useful form, whatever that is.

Ok, so we want a shared storage for several, related, branches. Now what is
the difference between the branch storage and the central storage? The only
difference I see is, that a shared storage may contain more than one head.

So we come to having a store with can only contain one head at any given
time, and a store which can contain several heads.

Then, if I understand correctly, the limitation to one head on a branch is
for simplicity to the user, not the code, right? The code could handle it,
probably with a few fixes. So if it is fixed, there is no difference betweed
branch and centralized store.

Now for normal branch the store is in the .hg metadata directory, while for
branch using central store it lives elsewhere. So let's just make a symlink
there and they are the same again. Well, with exception, that it does not
make sense for the shared storage to keep the checked out copy.

Of course on Windows, some alternative to symlinks would have to be
implemented. Eg. something like .lnk file.

Now for sake of simplicity for the user, I'd suggest to have pull merge (by
default) for noral branches. For the brnahces using shared storage, it should
also merge by default, we just need to keep the record which head to merge
to. Well, the head is the revision the checkout is from---and may not really
be a head in the shared storage at all. Also for pulling from a shared
storage we would need to specify the revision (and pull only ancestors of
that), but that should not make a big problem.

This proposal would somewhat loosen the bind between working copy and
a branch, but I hope it would keep the model simple and understandable.

--
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050912/bb4152b3/attachment.pgp