Hendrik Boom <hend...@topoi.pooq.com> writes: > 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.
badly. But there is a simple workaround; see below. > I presume that when I'm in the subproject directory, monotone will see > just the subproject. Yes; it looks for _MTN to indicate the project root. > But when I'm in the main project, to what extent is monotone aware of > the subproject? All files/directories in the subproject will appear as 'unknown' to the main project. > When doing things like mtn list known, does it see the _MTN file of > the subproject as a warning not to go there? No. > 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? You can, but that will be confusing. If you commit a changed file to the subproject, the file will still appear changed to the main project. > 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). It is a bad idea, because the _MTN/options file contains absolute paths that are valid for your machine, but probably invalid for others using the project. The _MTN/revision file changes with each commit. > Or what? The workaround is to put the subproject root directory in .mtn-ignore for the main project. .mtn-ignore should then be committed in the main project, which means it has knowledge of the subprojects, reducing independence. But it's better to checkout the two projects in parallel; there's no reason the directory structure has to match the main/sub project structure. > I'm thinking of using this in a context where the subprojects are > really independent projects in their own right, Ok. > but the main project contains their workspaces, This suggests you are using the term "workspace" differently than mtn does. In mtn, it means "the directory tree checked out from one mtn branch". And "project" means "a set of related branches in a mtn repository" (more than one branch for parallel development), although that's less well-defined. A "project" never contains a "workspace"; a workspace is an instance of a project. Which is sort of what you described above, I'm just verifying the terminology. If you check out the main and sub as described above, the correct mtn description is "the main workspace contains the sub workspaces". If you put the sub workspaces in the main .mtn-ignore, then the main project does not contain the sub project. Why do you want to do this? What problem does it solve? One thing it enables is "find" from the main project root. But if you check out the main project and subproject as sibling directories in the same super-root, you can still do that. That's what I do for my related mtn projects. Another thing to consider is relative paths in main project Makefiles etc that refer to the subproject. They depend on exactly where the subproject is checked out. Nothing in the setup you've described _enforces_ where the subproject is checked out; other developers might ignore the policy and check them out as siblings, breaking the Makefile. A fix for that is to write Lua code to unify checking out and updating the related projects. That way, the relative paths in Makefiles etc are enforced by the Lua scripts. That can enforce checking out the subproject as either a sub or sibling directory. I do that for my related projects (as sibling directories); if you'd like to see the Lua code, let me know. Another thing to consider is the branching policy, and the workspace directory naming policy. Are there developer branches for all the projects, or only for the main project? How are the workspaces named? How does that affect relative paths? I normally name the workspace directory to indicate the mtn branch it is checked out from; that can break relative paths if the projects are not all branched together. I always branch all the related projects together, so I can safely modify _any_ of the code to fix something. But some code really is changed rarely, so other branching policies might make sense. > documentation files that organize the collection, and other files that > may or may not later become projects in their own right. All of those can stay in the main project; this is orthogonal to the issue of where to check out the files. It does mean the main project is aware of the subprojects, so putting the subprojects in the main project .mtn-ignore is more acceptable. > Assuming this model is feasible, of course. It is, with the .mtn-ignore workaround. But I don't understand what you think it gains you, compared to checking out the projects as sibling directories, and enforcing that with Lua scripts. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel