Centralized Storage, round 2

[Aaron Bentley]

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

Robert Collins wrote:
>>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 ?

That is the only thing that comes to mind.

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

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

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

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

No, it's never my intent.  I want to retain all my branches forever, but
I don't want a bunch of junk in my home directory.

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

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?

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

> In particular, if
> one chooses to use the same structure you propose, it would work
> identically.

In my proposal, the path-to-central-store is only for local users, so it
can be specific to the filesystem.

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

iD8DBQFDJZ5k0F+nu1YWqI0RAjNlAJ4kMMjhpAjoJu2dvxkj3wprOOweJACbB3Jl
Am68rThnxE8s35+dWU7gvhY=
=GMM2
-----END PGP SIGNATURE-----