[RFC] move revision-history from branch to shared repo

[Aaron Bentley]

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

James Blackwell wrote:
| On Mon, Mar 20, 2006 at 01:06:18AM -0500, Aaron Bentley wrote:
|
|>James Blackwell wrote:
|>| I'm kind of curious. What is the general opinion of moving the
|>| revision-history for branches in shared repositories from the branch to
|>| the shared repo?
|>|
|>| Benefits:
|>|
|>|  - Ability to audit a shared-repo and check for prunable revisions.
|>
|>You can already do this.
|
|
| Ohh, I know that you can prune a specific revision but I didn't know that
| there was a check for prunable revisions. How does one do it?

You list all the directories (including sub-directories) in the
repository, find the branches, and look at their revision histories.

|>|  - create a new checkout or standalone branch based upon the information
|>|    stored in revision-history
|>
|>That doesn't sound like an observable feature to me.
|
|
| branches associated with shared repos seem to have a file named
| branch-history in .bzr/branch.

Is this hypothetical?  My repositories do not have any branch-history files.

| The lines in this file look like revision
| ids to me. This leaves me thinking that if this file were given a nice
| name like branch-history.bzr.dev then I could:
|
|  1. remove my bzr.dev branch with its working tree.
|  2. Later decide I want bzr.dev back
|  3. do something approximately equivilant "bzr branch --stored bzr.dev"
|     and rebuild the bzr.dev branch.

You're talking about removing a branch from the repository, then
restoring it later?  See this is what I use checkouts for.  They're safe
to blow away.  But there's nothing stopping you from renaming your
branch to 'branch-history.bzr.dev' or '.bzr.dev' or '.old-crap/bzr.dev'

I do think that when a user deletes a branch, they have an expectation
that they have deleted all the branch data, and it could be harmful to
not meet that expectation (e.g. nuclear launch codes).

|>This is the main problem with this idea-- you still need a 1:1 mapping
|>of branches and revision histories, and I can't see why it's any help to
|>store the revision history separately.  Hell, a branch mostly *is* its
|>revision history.
|
|
| Aye. Most of the metadata is this. A bigger part would be the working tree
| that comes with it.

No.  Branches in shared repositories do not have working trees.  This
makes them pretty cheap, so you can hold onto them indefinitely.  See my
repository (http://code.aaronbentley.com/bzr/bzrrepo), for example.  The
whole thing is 46 MB, which is smaller than a standalone branch of
bzr.dev (roughly 55 MB).  It also means that scanning for branches won't
~ involve scanning source directories.

(And yes, the code permits having working trees in a shared repo.  I
just think it's bad default behavior, so I haven't put it in the UI.)

| I'm not sure which of the metadata present for a
| branch is copied and which is stored in the revision.

I think the revision history is the only archival information in the
branch.  The rest of its data is for configuration.

|>Oh, and revision-history should be replaced with a last-revision pointer
|>before we consider this, anyhow.
|
|
| I'll look up and read the spec for this as soon as I have the opportunity.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEHmK/0F+nu1YWqI0RAvs0AJ4zIhA4M2Jn55o3Alk1F/v6Le4i7wCgh41J
3XclY7oRc+xch4lQlqs0KyA=
=A7gr
-----END PGP SIGNATURE-----