Re: [Monotone-devel] nested workspaces
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
[Monotone-devel] Thanks. Re: nested workspaces
On Fri, Dec 06, 2013 at 04:31:13AM -0600, Stephen Leake wrote: 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. Presumably the .mtn-ignore that you mention 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. Is there ever a case where it *is* useful for monotone in the main project to be aware of the files of the subproject? Is there ever a case where it would be useful *not* to mention the root directory of the subproject in the .mtn-ignore file? I'd like to hear of cases where this might actually be useful. I can imagine there might be some, but I can't actually imagine them. If not, should monotone by default use nested _MTN directories as a don't-go-here indicator? 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? (This, and the remaining questions were me testing boundaries for clarity, not nnecessarily things I was planning to use.), 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. Yup. 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. Agreed. 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. That seems to be what I want. 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. Well, actually, there is. I'm writing stories. Some are short, some are long and end up organised into many files. Each story, once it's well-enough conceived to be considered a story, ends up being a separate (sub)project. But there's also prewriting, where ideas and text fragments are thrown about long before there's any pretense of them being stories. These get looked through now and then, and sometimes they, in various combinations, become stories of their own. Whrn that happens, I make a subdirectory to isolate them from the general chaos and make a concentrated place to work on them. I use monotone as a way of being able to use multiple computers interchangably, to be able to find old scenes that have been written out and have to be resurrected, and, of course, as a backup mechanism. So each story's main directory is checked into a monotone branch of its own, so its further revision history doesn't get mixed with the completely different revision history of other, irrelevant stories. But the main directory, that contains all these subproject workspaces, is where all the initial inchoate thoughts are conceived and stored, as well as README files explaining the organisation that does exist, and various scripts that manage the whole thing. And it's all wrapped up in one big directory for convenience, to separate it from other things that have nothing to do with story writing. 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. Yes that's the way I'm using the term. And project means a set of related branches in a mtn repository (more than one branch for parallel development), There's little parallel development, except transiently, caused by occasional failure to sync. It mmight be different if I ws working on multiple-author novels, though.
