Centralized storage in bzr

[Martin Pool]

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?

Just that so far, removing a branch directory will at most lose
information that was only present in that directory.  This is a bit
different from CVS (where you can blow away clean working directories
at will) but not too surprising.  

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.

> Every now and then, I want to blow away a working tree like I could with
> Arch, knowing that I wouldn't lose the branch data doing so.  Sometimes
> it's because I'm done working on the branch, and other times, it's
> [because the tree has gotten into a bad state.]

Being able to cleanly remove branches that didn't work out is a
strength of the branch=directory model; the downside is that it's more
important to make sure they're never lost accidentally.

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.

* I just want to delete this branch.

* My working copy is messed up and I want a new one based on the same
  branch.

> > At the moment I have in mind a perhaps more conservative approach of a
> > search path for objects.
> 
> > These other branches are strictly read-only, used just as a local
> > lookaside cache.
> 
> 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.

> > So do you mean each working directory would include a file containing
> > ANYPATH, and history wouldn't normally be stored in the working
> > directory?
> 
> Yes, the idea was to have the working tree store working tree data,
> branch id and last-committed-revision.  The branch data would be stored
> centrally.

OK, that sounds reasonable.

> > This seems a lot like the idea of "bound branches" -- branches whose
> > history is stored elsewhere, possibly in a place shared between
> > multiple working copies.  I think that will be good for some
> > situations but I don't think it should be the default.
> 
> It's somewhat like bound branches, because those also had the
> requirement that you should be able to get the branch from just one URL.
> But AIUI, those have a fixed location and so they can't be branched
> with cp.  

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

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

??

-- 
Martin