Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes: [...]
> There is another approach built into monotone. If you consider having > each sub-project in their own branches (let's call them A, B, C and so > on for the sake of simplicity), and then a branch called COMMON for > the common tree. With such a construct, each sub-project can be > introduced into COMMON as follows: > > mtn merge_into_dir A COMMON proj-A-dir > mtn merge_into_dir B COMMON proj-B-dir > mtn merge_into_dir C COMMON proj-C-dir > > Of course, the COMMON branch is a project of its own, and can have > it's own files and so on alongside the sub-project directories. > > To apply changes made later on in the sub-project's own branch, a > propagate does the trick: > > mtn propagate A COMMON > > The result is that anyone that checks out the COMMON project will > automatically get all required sub-projects along with it. There's no > need to keep track of special instructions to create the common tree. I think in the specific use case, the extra directories are things that aren't required. That is, there's some common stuff, and there's a space for me to put stuff in a directory if I want, and then that'll get built, too. So I think to use merge_into_dir in this case, each user would need to branch COMMON, then use merge_into_dir to merge in their directories. That would work OK, although it doesn't seem likely to be as convenient to me as just checking out my project inside a checkout of COMMON: if I do that, then I can make modifications and commit them right in a buildable tree. With the merge_into_dir case, as far as I understand it the merged-in branches are supposed to be modified in their individual branches, and propagated to the common one. But in this case, I think the common one is the only one that's usable. So I think merge_into_dir wouldn't really work for this, unless I'm misunderstanding something (which is entirely possible: I've not actually used merge_into_dir, but I use nested checkouts regularly)? _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
