partial branches

[John Arbash Meinel]

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

Erik de Castro Lopo wrote:
> Erik de Castro Lopo wrote:
> 
>> I would now like to make one or more public branches which are a subset
>> of the internal project (ie some directories missing in the public
>> branches).
> 
> I should mention that I still need to merge between branches with
> screwing any thing up.
> 
> Erik

Well, there are a couple of possibilities, some easier than others.

1) Just remove the files and publish the new branch. (bzr rm subdir, bzr
commit). The current working tree won't have the files, but they will
still be around if someone does "bzr revert".

So this probably doesn't help you much.


2) Regenerate the history and remove the unwanted files. This is a
difficult one, but it would mean that you would have a branch without
the unsafe files. With a little bit of work, you can get it to
synchronize with the other one, though I would recommend just splitting
it up into 2 projects if you go this route. (one with public stuff, and
one with *just* the private stuff)

We don't have a lot of automation assistance with this (yet), since you
kind of need to create a language for how to specify what files to keep,
and which ones to ignore. I could probably help you with this if it is
important.


3) If you don't care about publicizing the history of the public
project, you can use a simple trick:

cd private
bzr export ../public
cd ../public
rm -rf stuff I don't want
bzr add --file-ids-from ../private
bzr commit -m "First snapshot of the public project"

Now you have a branch with no history, but matching file ids to the
private project. If you then do:

cd ../private
bzr merge -r 0..-1 ../public

This will probably cause lots of conflicts (since the files show up as
"new" in the public side).

bzr revert .

The final "." is important. It reverts all of the file-content changes
without reverting the "pending-merge".

bzr commit -m "merge and reject public project changes".


At this point you have established a link between the public project and
the private one. Any changes in the public project can be merged back
into the private project. With a simple "bzr merge ../public".

You have to be careful not to do "cd public; bzr merge ../private". But
it will be obvious because that will add back all of the files you are
trying to hide. A simple "bzr revert" will remove those files and remove
the pending merge flag, which means that a pull from public still won't
copy the extra files.

However, you need to make sure that your local "public" branch isn't the
same as your truly public branch, because a mistake like that will bring
over the private branch's history into the repository. (It won't be
marked as in the ancestry, because you didn't commit the merged).

This isn't really a big deal, because you will typically need to cherry
pick the changes from the private branch to the public branch anyway.
(Because you don't want the extra files.)

This is getting a bit long winded, and I'm hoping it is more helpful
than confusing. But generally it is what I would recommend. (As long as
you don't need 'bzr log' and 'bzr annotate' on the public branch).

Erik Bågfors was using this to have 'client' branches. So he could have
a real bzr branch on a 3rd parties machine, make changes and merge them
back into his core branch, without exposing other private data.


I can try and make it a bit more 'step-by-step'. And maybe something
like this deserves a real document / wiki entry.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOe9AJdeBCYSNAAMRAr2gAJ9eONRY7U2DxOhOdwzZ8NYv+dRapQCgodN0
ytQnDzoFwOlSjumuFYNqH5k=
=PjpC
-----END PGP SIGNATURE-----