[Monotone-devel] Thanks. Re: nested workspaces

[Hendrik Boom]

On Fri, Dec 06, 2013 at 04:31:13AM -0600, Stephen Leake wrote:
> Hendrik Boom <address@hidden> 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.

> 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.

Yes.  

> 
> 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.

Given what I'm doing, there isn't much of a global Makefile.
There might be someday, if some of the idea soup were to crystallise 
into code intead of text.

> 
> 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.

.mtn-ignore does seem to be what I'm looking for.

> 
> > 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. 

The main directory is the natural place to put the idea soup that 
hasn't crystallized into specific projects yet.

-- hendrik