Re: [Monotone-devel] Nested projects in workspace

[Jonathan S. Shapiro]

On Fri, 2006-08-04 at 22:33 +0200, Richard Levitte - VMS Whacker wrote:

> shap> USE CASE:
> shap> 
> shap> The use case that I know best is the one for the EROS tree. Our
> shap> workspace tree has a basic directory structure, and within that there
> shap> are places where users can introduce their own "projects" but still live
> shap> within the EROS master build system. The issue is that their projects
> shap> are independent of ours for configuration management purposes, but must
> shap> live within the common tree.
> 
> I see a problem with your approach, and it's that anyone who wants to
> build the common tree MUST know what sub-projects must live where.

This boils down to the question "how should interacting projects be
organized in a workspace". The answer is intrinsically project
dependent.

In our case, there is a single directory where overlay projects get
placed, and it works very well for us. Other projects would certainly
want different solutions.

> There is another approach built into monotone.  If you consider having
> each sub-project in their own branches (let's call them A, B, C and so
> on for the sake of simplicity), and then a branch called COMMON for
> the common tree.  With such a construct, each sub-project can be
> introduced into COMMON as follows:
> 
>       mtn merge_into_dir A COMMON proj-A-dir
>       mtn merge_into_dir B COMMON proj-B-dir
>       mtn merge_into_dir C COMMON proj-C-dir
> 
> Of course, the COMMON branch is a project of its own, and can have
> it's own files and so on alongside the sub-project directories.

This is exactly what we DON'T want. The intention is to keep the overlay
projects very firmly separated from the base.

In practice, the use case often involves a customer whose overlay
project is proprietary or unreleased. The LAST thing they want is to
merge it into the base, and the last thing that WE want is to bite off
any legal problems that this might create as a result of merging
third-party IP.

shap