Centralized Storage idea (Was: Centralized Storage)

[Aaron Bentley]

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

Jan Hudec wrote:
> 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?

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.

So if you have two branches named bzr.dev, one could be stored as
bzr.dev, and one could be stored as bzr.dev-1.

The only reason why the names of the branches in the central store
matter at all is for remote users.  The names should (but don't *have*
to) be comprehensible to remote users.

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

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

Pardon?

 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.

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

I don't see why there's a need for it to be any kind of link.  We can
just have a file that's used to find the central store.

> 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.

> 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.

> 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?

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

iD8DBQFDJhbK0F+nu1YWqI0RApgyAJ9y2ZGnOlzsbWnJEtxw3iKwN/piXACffBU7
QHViUOUCwb/me+Qn0px9AKs=
=LhJe
-----END PGP SIGNATURE-----