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 <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/monotone-devel _______________________________________________ Monotone-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/monotone-devel
