monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Sharing subprojects between projects


From: Anthony Williams
Subject: [Monotone-devel] Re: Sharing subprojects between projects
Date: Wed, 04 Jul 2007 16:13:59 +0100
User-agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.19 (windows-nt)

Bruce Stephens <address@hidden> writes:

> Anthony Williams <address@hidden> writes:
>
> [...]
>
>> Also, in my case it doesn't work so well --- I would like to make
>> changes to the subproject as appropriate to the master project it's
>> being used in, optionally propagate these changes back to the
>> subproject branch, and still be able to pull in changes made to the
>> subproject elsewhere.
>
> So (in current terms), you'd want to branch the subproject,
> merge_into_dir that branch into the main branch (and propagate from
> then on).  Generally you'd then want changes just to propagate into
> the branch of the subproject, but occasionally you'd want them to go
> into the original.
>
> So if changes to a merge_into_dir could be somehow committed to the
> branch, you could do something close to what you want now just by
> adding an extra branch (to represent the variant of the subproject
> that's for this master project).  As you say, pluck comes reasonably
> close, though there are likely problems because pluck is basically
> "patch".
>
> I'd just use nested checkouts in this case.  With this extra branch
> that ought to work OK.  It would be nice to have a little more
> support, but as I mentioned, what that ought to include isn't obvious.

Thanks for everyone's suggestions on this. I've been mulling it over and
trying out a few things.

Here's what I think is my ideal solution:

Shared library is on branch shared.lib

Application 1 is on branch app1
Application 2 is on branch app2

New command branch_into_dir <source branch> <new branch> <directory>
This command needs to be run in a workspace. <new branch> must not exist as a
branch name.

A new branch is created called <new branch> as a copy of <source branch>. This
branch is checked out into <directory> within the current workspace, and this
fact is registered in the database. A commit anywhere in the workspace will
commit both the branch in the nested directory and the main branch at the
workspace root.

cd /projects
mtn co app1
cd /projects/app1
mtn branch_into_dir shared.lib shared.lib.app1 lib
# app1/lib now contains the code for shared.lib
mtn ci
# commit changes
echo foo >> file1
# append something to a file in the workspace
cd /projects/app1/lib
echo bar >> file2
#edit file2
echo baz > new_file
mtn add new_file
#add new_file
mtn ci
#file1 checked into app1 branch
#file2 checked into shared.lib.app1 branch
#new_file added to shared.lib.app1 branch

Changes from the new shared.lib.app1 branch can be propagated to and from the
shared.lib branch using propagate as normal

mtn propagate shared.lib.app1 shared.lib

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL





reply via email to

[Prev in Thread] Current Thread [Next in Thread]