Centralized Storage, round 2

[Robert Collins]

On Sun, 2005-09-11 at 16:25 -0400, Aaron Bentley wrote:
> ...
> Storing all the branch data centrally means that there is a single
> location in which all a user's data is stored.  This has advantages for:
> - - publication (just point your DocumentRoot at one directory)
> - - mirroring and backups
> - - interactive exploration
> 
> As well, it means that working trees can be deleted without destroying
> the branch data.

What branch data are you thinking of? Just the revision-history surely ?

> Finally, they retain the ability for remote users to download a branch
> using just one location.

Rob Weirs branch has this ability too.

> If the branch data is stored in the working tree, both the centralized
> store and the working tree must be publicly accessible.  The working
> tree must refer to the centralized store using a relative path, so that
> the same path is applicable locally and remotely.

Uhm, I don't see the linkage here. The policy for sharing or not is
surely per branch, so the remote branch could be not shared and the
local one shared, or vice verca.

> Using a relative path imposes restrictions on moving the working tree,
> because some moves will change the meaning of a relative path.  For
> example:
> 
> If the central store is at ~/central, and the branch is at
> ~/programming/bzrtools, then the relative path will be ../central.  mv
> ~/programming/bzrtools bzrtools will cause the relative path to refer to
> ~/../central.

I don't understand how this is different with an 'all data is in the
centralised location' model - the property of needing to find that
location doesn't change.

> Keeping the branch data in the working tree also means that if you want
> to publish the branches, you must work in a directory that is under the
> DocumentRoot of your web server.

??

> It also makes backups and mirroring harder, as your branches are no
> longer likely to be in the same place.
>
> And of course, deleting working trees destroys the branch history.

Which is the intent of the user surely? One of the big things about bzr
is that it consolidates working tree and history.

> My proposal is not flawless.  The main problem David Allouche found with
> it was that by default, it used the branch directory name as a unique
> name.  I had assumed that anyone who needed multiple branches with the
> same directory name would have to set their unique branch name manually.
>  This could be problematic with configs.  (or maybe not; cm build-config
> - --branch-suffix "-newthing")

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).
- It makes it possible to delete a working trees revision-history by
mistake (because that is no longer associated with the working tree).

The arguments about backing up and mirroring dont make any sense to me
in the scope of achieving centralised storage - they make a lot of sense
in terms of automating those functions, but I would like to have
centralised storage without imposing those other requirements on it.

I also don't understand your concerns about relative and absolute urls -
as far as I can see it will work JustFine with nearly any combination of
virtual hosting, relative paths and absolute paths. In particular, if
one chooses to use the same structure you propose, it would work
identically.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050913/26ff0dea/attachment.pgp