I found this works very well with monotone.
monotone will see the sub project in the subproject and the overall
when outside; unless you specify the root directory which many command
have the option for.
It includes by default ignoring _MTN, so adding that project you will
have to specify to ignore the ignores.
For tracking purposes, I avoided doing commits to the main project and
only commited in the subproject, and used propagate to merge the
changes to the main... then I could double check I didn't miss a
commit by doing a diff on the parent also
You can construct a main project from a sub project by using the
pivot_root feature; create a new root directory, and then pivot the
root to that, so the existing project becomes included as a directory.
NEVER propagate from the overall project to a subproject.
You can really only keep the _MTN/revision information because options
contains workspace specific information... which becomes somewhat of
an issue updating the checkout of the subprojects to get a good
options file.
I do think this confuses other programmers as noone was able to
continue without always asking how to propagate.
I thought it would be easier to have a project that maintained a
structure between the subprojects so they could have some knowledge of
each other through the master project... but it really isn't. Each
part should build itself into a installed state, and the other
projects should target that installed information instead of direct
sources.
On Thu, Dec 5, 2013 at 2:19 PM, Hendrik Boom wrote:
> I've never found a clear discription of what happens with nested workspaces.
> Maybe I just haven't looked enough.
>
> For example, I may have a project and a subproject.
>
> I checkout the project, and get a directory fill of stuff, including a
> _MTN directory.
>
> Subsequently cd into that and check out another project into a new
> directory I'll call subproject. It too has a _MTN directory.
>
> How do these two interact.
>
> I presume that when I'm in the subproject directory, monotone will see
> just the subproject.
>
> But when I'm in the main project, to what extent is monotone aware of
> the subproject? When doing things like mtn list known, does it see
> the _MTN file of the subproject as a warning not to go there?
>
> Or can I take files that are part of the subproject and add them into
> the main project as well, so that both monotones apply updates to the
> same file?
>
> Or can I even go so far as to put the _MTN directories of the
> subproject under revision control as part of the main workspace? (I
> suspect this is a bad idea; I'm interested in just what the limits
> are).
>
> Or what?
>
> I'm thinking of using this in a context where the subprojects are
> really independent projects in their own right, but the main project
> contains their workspaces, documentation files that organize the
> collection, and other files that may or may not later become projects
> in their own right.
>
> Assuming this model is feasible, of course.
>
> -- hendrik
>
>
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
