Centralized storage in bzr

[Aaron Bentley]

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

Martin Pool wrote:
> On 14 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 
> 
>>Sure.  Are you saying you think it's easier to unexpectedly lose
>>information for centralized branches?  Could you expand?

> If there are directories holding information for multiple branches
> then we need to be more careful that before someone deletes one,
> they're totally clear on what will be lost.

Sure, if someone decides to delete their central storage, they'll lose
everything.

However, if the user has to set up their central store, we can at least
hope that they understand the significance of deleting it.

Definitely, there should be only one command necessary for a non-user to
retrieve a bzr-sourced project.  Central storage would be bad in that
scenario.

> It seems like there are a few scenarios:
> 
> * I still want this history, but I don't want to see it.
> 
> * I want to keep this history but I don't need a working copy.

Hmm, I wonder if it would make sense to have a 'bzr release' command
that would store the branch in the central storage and remove the
working directory.

> * I just want to delete this branch.
> 
> * My working copy is messed up and I want a new one based on the same
>   branch.

I should point out that 'bzr revert' only sort-of helps here, because it
doesn't clean unknown files out of the working directory.  We could add
a flag to revert to remove unversioned files, I guess.

Oh, by the way, why is it that 'foo.orig' is default ignored and
'foo.rej' is not?

>>>At the moment I have in mind a perhaps more conservative approach of a
>>>search path for objects.
>>Sure, we can do that.  It seems like an awkward way of doing it, though.
>>I'd like a way for it to happen easily and smoothly.
> 
> 
> That's true.

I thought about having bzr keep track of every local branch you invoke
it in, and then using all those branches as cache automatically.  But
that starts to sound like tla's search-siblings-for-pristines approach,
which was definitely surprising to most people.  Also, it could cause
spurious errors, if it tries to access old and/or broken branches.

> If you copy a bound branch you'll get another branch bound to the same
> parent -- like copying a CVS checkout.

Right, so it's more like having two copies of the same branch, not two
separate branches-- If both try to commit at the same time, only one
will succeed.

>>Also, from IRC discussion, I thought that with bound branches
>>you could choose either to the working directory or to the bound
>>location, which would mean that there would be branch history stored in
>>the working tree too.

> ??
Did you want some more verbs with that :-)?

Maybe a month ago, people were talking on IRC about Codeville and how
they have 'commits' and 'snapshots'.  Snapshots are like commits, only
they write to local data, not the remote location.

Someone claimed that bzr would be able to support that when bound
branches were implemented.  It might have been Robert Collins, I guess.
 I can't find a reference to it in the loglibrary logs.

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

iD8DBQFCsDAb0F+nu1YWqI0RAnQMAJ41tvTLJ8OYqSXr+neGnfmC+rPQgwCeNBtU
TjtRzGNSZ0/KQrdyfSOhkzs=
=fgmU
-----END PGP SIGNATURE-----