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
