Centralized Storage, round 2

[Robert Collins]

On Mon, 2005-09-12 at 11:27 -0400, Aaron Bentley wrote:

> >>Finally, they retain the ability for remote users to download a branch
> >>using just one location.
> > 
> > 
> > Rob Weirs branch has this ability too.
> 
> Well, kinda-sorta.  You have one location, and it refers to another
> location.  In mine, you really have just one location:
> http://bazaar-ng.org/central-store/bzr.dev

And something in the tree refers to it. 

> >>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.
> 
> I am assuming the case where the user wants to share their data.  The
> other case isn't interesting.
> 
> So to reiterate:  If the branch data is stored in the woking tree, AND
> THE USER WANTS TO SHARE IT, both the centralized store and the working
> tree must be publicly accessible.  The working tree mist refer to the
> centralized store using a relative path, so that the same path is
> applicable locally and remotely.

Why? Is this because you are thinking 'rsync to publish' ? I don't see
ANY REQUIREMENT for local and remote copies to have the SAME CENTRAL
store. 

I'm about 95% positive this is a disconnect between us here.

> >>Using a relative path imposes restrictions on moving the working tree,
> >>because some moves will change the meaning of a relative path.
> 
> > 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.
> 
> If branch data is in a cetralized location, remote users use the central
> location, not the working tree, so the working tree can use an absolute
> path to refer to the centralized location.
>
> >>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.
> > 
> > 
> > ??
> 
> This is what I understood from our discussion.  How do you propose to
> publish branches seamlessly in Weir's model?

'bzr push'

> ... 
> > 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.
> 
> > - It makes it possible to delete a working trees revision-history by
> > mistake (because that is no longer associated with the working tree).
> 
> No, I think it makes it harder to delete a working tree's
> revision-history by mistake.  Yes, if you delete your central store, you
> lose everything.  But what good is a revision-history if you've deleted
> your store?

I was referring to someone cleaning up their 'central branches' so that
they can reuse a branch name, and the resulting chaos that would cause.

> > 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 see an opportunity to solve many problems at once here.  I think it
> would be really great if, as in Arch, the only thing I need to do to
> make sure my data is backed up and mirrored is branch and commit.
> 
> > I also don't understand your concerns about relative and absolute urls -
> 
> Relative urls mean you can't move your branch.
> Abolute urls mean your urls have to match your filesystem, e.g. my home
> directory would have to be at
> "http://aaronbentley.com/home/abentley/central-store" if I had the
> absolute path "/home/abentley/central-store"
> 
> > as far as I can see it will work JustFine with nearly any combination of
> > virtual hosting, relative paths and absolute paths. 
> 
> I don't see how you could possibly think that.

Well, the combinations I know about are:
my local config:
~/central-store is the store
branch A has a store-location of /home/robertc/central-store and a
x-pull location of 'sftp://server/home/robertc/public_html/mybranch

my published config:
sftp://server/home/robertc/public_html/bzr is the store
sftp://server/home/robertc/public_html/mybranch is a branch with a
store-location of '../bzr'
http://server/~robertc/mybranch is where I tell other people to pull
from.

And I publish via 'push' or by rsync of the store and push of the
branch. No, I cannot push the branch via rsync because the central store
location is different in the two copies.

Thats about as complex as I can imagine users encountering, it has
single documentroot.

I don't see how your proposal will behave any better with rsync, because
the pointer to the central store changes with each machine.

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/5bfffab7/attachment.pgp