Forking

[John Arbash Meinel]

Nathaniel McCallum wrote:
> Just curious if there is any accepted tree forking practice with bzr.
> For instance, I have a subdirectory (of a large project) that I want to
> split out into its own branch.  However, as it a small directory (50k or
> so), I don't want the history of the whole tree (~400MB), just of the
> related files.  Any thoughts?
> 
> Nathaniel
> 

In the future, this might be supported. We at least discussed this sort
of thing for:
http://bazaar.canonical.com/NestedTreeSupport

It is tricky to get it all correct.

At present your only options are to carry over all of history, or carry
over no history. You can branch, prune, move around, and then commit,
but you will still have all of the history.

*WARNING* what follows is not supported, it should work, but you may
nuke something. You have been warned.

You could copy the current branch, and delete all of
.bzr/revision-store/*, .bzr/weaves/*, etc. And then truncate
.bzr/revision-history
I think that is enough to make it look like a newly initialized tree,
which just happens to have the right file-ids, etc. If you then do your
pruning, etc you will have a tree where changes should occur to the
right file ids, so that you can merge back into the original project.

So after prunning, commit the new branch. This should give you a
revision id. (the only entry in .bzr/revision-history).
If you copy that id into the parent branch's .bzr/pending-merges, and do
a commit, it should record that you have reconciled the differences
between the trees.
You may need to do the same thing to the child tree, so that it doesn't
try and pull all of the main branches changes everytime.

Anyway, at this point you should have your original branch with the
subdirectory and it's files, and a second branch which has some of the
same files.
Changes made in the child should be mergeable into the main tree. I
don't know that you can merge the other way without getting lots of
problems. I think you'll just get some "changes made to missing file foo".


If you are interested in adding functionality such that you can make a
cleaner break, it would be possible to do so.
One change we have discussed (for many reasons) is that each directories
inventory should be a separate file, rather than 1 large
inventory.weave. At that point, you could copy over all of the weaves
for just the involved sub directories, and then fix up the
revision-history so that you don't see revisions which didn't change
your specific files.
This hasn't been thought completely through, though. Here are a couple
specific problems:
1) Revision texts contain a hash of their inventory. This is desirable
because it allows integrity checking. If you break out subdirectories,
then your hash now points to some stuff that you no longer know about in
the current tree.
2) Same thing for revision signatures.
3) At present, bzr has the mindset that if you have the revision file in
your store, that implies you have all of the inventory and text weave
information to regenerate that revision. You would break this, because
now you only have a subset of it. You could just copy the inventory
information, and not the text weaves, which helps with 1 and 2, but
means that stuff like "greedy-fetch" needs to parse the information to
see if it is missing entries that it might need.
4) In general, we don't support a lot of history pruning, because that
means something could disappear. We are using a revision control system,
to keep track of history.

Consider if the future ideas of repositories and checkouts don't support
your desires better. A repository is a grouping of branches, such that
they share history information. And checkouts are working trees that
don't have the branch information locally.
With this format, creating a new branch is cheap, since all of the
history is shared, and creating a new working tree is cheap, since it
just points to the other location.
I think repos and checkouts will exist in less than 1 year.

Some things to consider,
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051215/8c8bbd21/attachment.pgp