Centralized Storage idea (Was: Centralized Storage)

[Jan Hudec]

Hello,

I apologize for top-posting, but I want to clarify my original post
first and than will reply to some specific points.

First, lets state the terms:
- TREE is the working copy, either with a store, or refereing to shared
  store. Actually in the end I propose the working copy to be optional.
- STORE is where the history is stored, both metadata and revision data.
- HEAD is a revision with no descendants (ie. the last commit in a
  branch).

Now what I propose is, that there only should be one store format
(including layout and everything). And to take it further, since the
shared store is the same as the one in a tree, I suggest *actually
making it a tree*.

So, again, there is only one object -- a tree. The working copy would be
optional (you don't need it for publication or backup...). And there
would be 'path to the store', which would be '.' for normal trees (ie.
not sharing storage' and a path to the tree with the shared store
otherwise.

Now of course trees will have to allow mutliple heads.

On Mon, Sep 12, 2005 at 20:02:12 -0400, Aaron Bentley wrote:
> Actually, in my centralized store proposal, the naming of branches in
> the central store doesn't matter at all to the local user.  Branches are
> identified with a combination of branch-id and last-commit.

In my proposal, branches are not identified. Revisions are identified
with normal tags. Some automated tagging of the head on commit is
desirable.

> [...]
> However, if remote users are not a consideration, then the branches can
> just as easily be called asdfjf and gjhte in the central store.

They are not named in that case--they do away with the revision ids.

> > Now for normal branch the store is in the .hg metadata directory,
> 
> Pardon?

Sorry, I meant .bzr

>  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.
> 
> That would not work very well if the branch was copied using cp -r.

But it would if it was cp -a ... Anyway, this is a technical detail. It
can be a file, for example .bzr/store, containing the path. The key idea
is, that is is the same whether the store is shared or not.

> [...]

> > 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. 
> 
> I don't understand why we would need to change our merge behavior.

... because the shared store would be a *tree*. But it would have
multiple heads, which is currently outlawed for trees. So it would no
longer be outlawed, it would just not happen by default (except for
shared stores).

> > Well, the head is the revision the checkout is from---and may not really
> > be a head in the shared storage at all. 
> 
> I don't know what you mean by head, but we can't store just a single
> revision.  Because each revision may have multiple parents, we don't
> know which ancestry to follow.

I hope the definition above makes it clear now.

> > This proposal would somewhat loosen the bind between working copy and
> > a branch, but I hope it would keep the model simple and understandable.
> 
> That's my goal too.  Have you had a look at my proposal?

Yes. The goal is basically the same, but I am taking things a little bit
further by saying, that when the shared store contains everything a tree
would, it can *be* a tree.

--
						 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/20050913/bc4e5c09/attachment.pgp