Checkouts? Or just light bound branches?

[Denys Duchier]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> Denys Duchier wrote:
>> I probably have missed something yet again, but i really want a checkout to have
>> a workingtree_location because I want the ability for multiple checkouts to have
>> overlapping workingtrees.
>
> You'll have to explain what you mean.  On the face of it, it sounds like
> you want to have a single directory in which some of the files are from
> one branch, and some of the files are from another.  This is not
> something we were planning on doing (to put it mildly).

I did give an example of what I had in mind in an earlier message: I would like
to be able to have under revision-control certain system files.  However,
certain groups of system files belong to logically distinct branches.  For
example, I have a "logical" etc-update branch which ought to control 2 files:

	/usr/lib/portage/bin/etc-update
	/etc/etc-update.conf

It would be extremely convenient if I could have a number of branches, all
checked out at the root ("/"), and controlling different sets of files under
that root.

I am well aware that there are other (less direct) ways of achieving the same
thing, but it would be great if bzr could support this way of working directly,
and I believe it can do so easily.

The way I suggested earlier would be to have a checkout/branch directory (I
really am not sure what I am supposed to call it anymore), for example under
~/src/etc-update, that would have a "state variable" pointing to its
corresponding workingtree location, namely /.

In this fashion, I could easily modify the files in place, then go to
~/src/etc-update and commit those modifs.

I could also have two distinct branches both thinking they are in control of the
same files.  You are probably thinking: "this is crazy!", but it is not.  There
are certain patterns of work with Gentoo that would be facilitated this way.

For example, when updating portage, the etc-update and etc-update.conf files
will usually be overwritten.  I would then go to ~/src/etc-update.orig (a branch
tracking the Gentoo line of development for these files) and commit the mods (if
any).  I could then revert and then merge those mods into my branch, namely
~/src/etc-update, which as a side-effect would update the system files (i.e. in
the working tree) to my branch updated with the mainline fixes.

--Denys