Colocated Branches unified working tree

My observation above was flawed.

So can anyone offer a bazaar dependent solution that realizes the unified working tree concept mentioned in my original post?

I misinterpreted the statement: “possible to very easily share the same working tree and repository between those branches,” mentioned here: http://doc.bazaar.canonical.com/developers/colocated-branches.html regarding the operation of co-located branches and their effect on the content of the working tree. I originally thought each co-located branch would contribute, by applying a “union” operator, directories and files to the working tree resulting a unified image. For example, if branch A1 consisted of: “A1dir/A1File.txt” and branch A2 contained: “A2dir/A2file.txt”, I anticipated the resultant working tree would reflect the union of both: A1dir/A1File.txt and A2dir/A2file.txt. I interpreted the “easily share the same” to refer to both the co-located branches and working tree contents. However, instead of generating a unified tree, the working tree reflects the contents of the currently selected co-located branch exclusive of the other co-located branches. This notion of exclusivity is reinforced during a branch “swap” operation, when the current co-located branch is replaced by a different one. After a swap occurs, all the files/directories of the once current branch are considered conflicts - specifically “path conflict”s from the perspective of the new current branch and these conflicts present themselves for resolution. Continuing with the example above, given that branch A1 is current, the working tree reflects its contents namely: “A1dir/A1File.txt”. A swap replaces A1 with branch A2 as the current branch, adds the contents of A2 namely: “A2dir/A2file.txt” to the working tree and indicates a “path conflict” for “A1dir” and requests that the conflict be resolved.

I investigated using a “shared repository” scheme and a common “checkout” working tree as potentially offering a mechanism to create the desired goal of producing a unified working tree from several distinct branches, however, as far as I can tell, these features can't be coerced to achieve my goal.

If no one can suggest a solution within the scope of current bazaar features, then I'll attempt to create a unified project tree by employing symbolic links.

Have you looked at lp:bzr-colo

Hi Jelmer!

Thanks for your reply!

I have experimented with the colo module and, as mentioned above, when two or more branches are co-located, the contents of the working tree reflects only those directories and files contributed by the "current" branch. The problem becomes more apparent when there are uncommitted changes to the "current" branch and a different branch becomes current after performing a "swap" operation. In this situation, the uncommitted files are viewed as conflicts that need to be added to the current branch. Although, I've attempted to "bzr ignore" these files, bzr adds them to the current co-located branch even though I've manually "Mark conflict resolved".

If I'm not understanding a feature properly, and you believe colo can support a unified working tree that is a composite of all the co-located branches, can you suggest a command(s) that I should focus on?

Thanks again!

On Mon, 2011-06-06 at 01:41 +0000, WhisperingChaos wrote:
> Question #160044 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/160044
>
> WhisperingChaos posted a new comment:
> Hi Jelmer!
>
> Thanks for your reply!
>
> I have experimented with the colo module and, as mentioned above, when
> two or more branches are co-located, the contents of the working tree
> reflects only those directories and files contributed by the "current"
> branch. The problem becomes more apparent when there are uncommitted
> changes to the "current" branch and a different branch becomes current
> after performing a "swap" operation. In this situation, the uncommitted
> files are viewed as conflicts that need to be added to the current
> branch. Although, I've attempted to "bzr ignore" these files, bzr adds
> them to the current co-located branch even though I've manually "Mark
> conflict resolved".
>
> If I'm not understanding a feature properly, and you believe colo can
> support a unified working tree that is a composite of all the co-located
> branches, can you suggest a command(s) that I should focus on?
What you're describing is indeed the nested tree feature and not
colocated branches. You would need something like bzr-externals or
bzr-scmproj to use nested trees in current world bazaar.

Cheers,

Jelmer

It is more like overlays. Because he wants files in the same directory to be
managed by different branches. At least as I read it.
John
=:->
On Jun 6, 2011 11:41 AM, "Jelmer Vernooij" <
<email address hidden>> wrote:
> Question #160044 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/160044
>
> Jelmer Vernooij proposed the following answer:
> On Mon, 2011-06-06 at 01:41 +0000, WhisperingChaos wrote:
>> Question #160044 on Bazaar changed:
>> https://answers.launchpad.net/bzr/+question/160044
>>
>> WhisperingChaos posted a new comment:
>> Hi Jelmer!
>>
>> Thanks for your reply!
>>
>> I have experimented with the colo module and, as mentioned above, when
>> two or more branches are co-located, the contents of the working tree
>> reflects only those directories and files contributed by the "current"
>> branch. The problem becomes more apparent when there are uncommitted
>> changes to the "current" branch and a different branch becomes current
>> after performing a "swap" operation. In this situation, the uncommitted
>> files are viewed as conflicts that need to be added to the current
>> branch. Although, I've attempted to "bzr ignore" these files, bzr adds
>> them to the current co-located branch even though I've manually "Mark
>> conflict resolved".
>>
>> If I'm not understanding a feature properly, and you believe colo can
>> support a unified working tree that is a composite of all the co-located
>> branches, can you suggest a command(s) that I should focus on?
> What you're describing is indeed the nested tree feature and not
> colocated branches. You would need something like bzr-externals or
> bzr-scmproj to use nested trees in current world bazaar.
>
> Cheers,
>
> Jelmer
>
> --
> You received this question notification because you are an answer
> contact for Bazaar.

Jelmer:

I appreciate your suggestions regarding extensions that may implement a unified working tree concept. After scanning their purposes, bzr-scmproj seems to offer features that deliver the requested result. I plan to experiment with this extension and if necessary the other one later this morning and will post my opinion on its fidelity to supporting a unified working tree.

Thanks for your continued effort to resolve my question!

John:

Thanks for joining the discussion.

Yes, the “overlay” concept you mention seems to describe the unified working tree concept. The word “overlay” also sparked the following thoughts concerning version control, as integral to the programming environment.

Another, perhaps more familiar framework to describe the desired feature would be to view each branch as a C++ base class where directories are mapped to named structures and files to atomic data members of a given class. One could then use the C++ mechanisms of multiple inheritance or composition to generate a derived or composite class whose public interface represents the desired unified view.

Isn't it interesting how the goals of programming languages: reuse/adaptation and source code control overlap. It's tempting to expose a language like C++ and an ability serialize objects within the programming environment so one could use its language features to create and merge branches (derived class/composition) then “compile” the new program to generate the desired unified working tree.

The other noteworthy benefit form viewing version control as an object oriented programming environment, is the experience gained from the mechanisms developed by language designers and compiler implementations to facilitate reuse/adaptation. For example, the meshing/merging of data members from various base classes, and the resolution of potentially multiple copies of a class definition that is common to these base classes.

Furthermore the idea can be implemented by the CREATE VIEW statement (another adapter pattern), especially in RDBMSes that permit triggers on views, as you can construct your unified tree as the composition of several tables (branches). In fact, this approach is probably easier to implement than the C++ suggestion above, as an RDBMS environment already includes data (working trees, branches...), as well as a programming language.

I appreciate your rephrasing the request, as it forces me to think about my request from a different perspective.