Re: [Monotone-devel] Nested projects in workspace

[Timothy Brownawell]

On 8/4/06, Jonathan S. Shapiro <address@hidden> wrote:
> The manual seems to say that monotone takes the "one tree" approach --
> there is a top (root) directory for the project, and everything under
> that is assumed to be part of the project.

Monotone allows for unknown files in a workspace. The difference
between ignored and unknown is pretty much (1) whether they show up in
"mtn ls unknown" or "mtn ls ignored", (2) whether "mtn add --unknown"
adds them, and (3) whether trying to add them or their parent
directory will actually add them.

> In the EROS and Coyotos projects, we have found that this structure
> doesn't work for us. Several other OpenCM users have the same issues. I
> will describe one of the use cases below, but first let me describe the
> issue:
>
> ISSUE
>
> What we need is to be able to set up projects in subdirectories within
> the workspace. For example, we need to be able to do:
>
>   proj1-dir/dir1
>            /dir2
>            /proj2-dir
>
> In OpenCM, we identify this case by noticing the presence of a .opencm/
> subdirectory under the project root directory. This is analogous to the
> _MTN/ directory in monotone. When we are recursing up to find the
> project root, we stop at any directory D such that D/.opencm/ exists.
>
> When we are walking the workspace tree, and we are recursing into a
> directory D, we ignore the directory entirely if there exists a
> subdirectory D/.opencm/
>
> Does monotone already handle this, or does it have something analogous?

Not exactly.

> Depending on the answer, would you consider a patch to add this behavior
> or (if it already exists) clarify this part of the documentation?

I can't speak for everyone, but I wouldn't object. We might want a way
to override it, but then your suggestings for .mtn-ignore would allow
for that.

> USE CASE:
>
> The use case that I know best is the one for the EROS tree. Our
> workspace tree has a basic directory structure, and within that there
> are places where users can introduce their own "projects" but still live
> within the EROS master build system. The issue is that their projects
> are independent of ours for configuration management purposes, but must
> live within the common tree.
>
> So far, we have been able to organize the tree in such a way that
> third-party projects have a single top-level root directory, so all we
> needed to do to support this in OpenCM was sensitize the client to the
> possibility that a subdirectory might contain its own project.