[Monotone-devel] Re: Sharing subprojects between projects

[Bruce Stephens]

Anthony Williams <address@hidden> writes:

[...]

> I tried using merge_into_dir to add the shared_project files as a subdir of
> project1, which sort-of works, but now I have to remember to pluck the changes
> back to the shared_project branch. Also, if I add a file in
> project1/shared_project and then pluck that change back to shared_project,
> then a subsequent propagate will break, complaining that the two adds
> conflict.

Or deliberately make the change in the original branch, propagate, and
update your tree, of course.

> What's the best way to do this with monotone?

Don't know.  It's a little tricky in anything other than CVS or
subversion.

It's easy enough in most systems (including monotone) to check out
branches inside a checkout (so you have nested workspaces).  Things
like "commit", "diff", "update", etc., won't go into those workspaces,
though, and even if they did, it would likely be confusing (a commit
of multiple branches wouldn't be atomic, and couldn't give a single
revision, for example).

Also things like "ls unknown" don't (yet) notice nested workspaces, so
they're likely to report the entire contents as unknown (when they're
not---they're correctly committed into a different branch).

Things like "ls unknown" are surely fairly easy to fix and
uncontroversial.  Just needs somebody who's bothered enough by it to
work on a patch.

Other stuff seems less easy.  I don't think anyone has a wholly
convincing model of how things ought to work, but there are several
examples of things that do bits that are useful (configs in GNU Arch,
the forest extension in mercurial, submodules being worked on in git).