splitting a project tree

John D. Mitchell jdmitchell at gmail.com
Mon Mar 10 16:19:49 CDT 2008

On Mon, Mar 10, 2008 at 10:41 AM, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
>  Another alternative would be for me to just use two repositories with
>  unrelated initial revisions:
>  1) split ns-3-dev into ns-3-core (only contains src/core) and ns-3-model
>  (contains everything but src/core) with the convert extension.
>  2) pull ns-3-core into ns-3-model and perform an initial merge:
>  resulting tree should be equivalent to the previous ns-3-dev. Let's
>  rename it to ns-3-dev.
>  3) work on ns-3-core, commit in ns-3-core and test ns-3-core by
>  branching ns-3-dev and re-pulling ns-3-core into it. When test is
>  completed, push merge into master ns-3-dev.
>  This:
>   - does not change the current developer experience at all (_very_
>  good)
>   - allows the 'core' developers to work on their own stuff and test it
>  without impacting anyone else (_very_ good)
>   - allows merging from 'core' to 'models' (_very_ good)
>   - will _not_ work very well if someone mistakenly commits changes to
>  the 'core' code in the aggregate tree. Is there a way to deal with
>  this ? To make sure that this does not happen ?
>   - does not really allow me to add _some_ files to 'core' which are
>  never merged in 'models'. i.e., if I want to add special files just to
>  do basic build and testing of the 'core' code, I can't or I have to
>  delete them prior to every merge into 'models'. And even that might not
>  work very well.

Do you *need* the publish the source for the "core" in the "model"
repo?  I.e., the way that I deal with libraries that my applications
need is to have each library in its own repository and then explicitly
check-in the built object (.obj, .jar, etc.) into the application's
repository.  That way, the people hacking the application/"model"
can't directly hack the core code but the core developers can hack it
in their core repo and test it in their "model" repo with a simple
file copy.

This explicit separation approach also deals nicely with your last
point.  I.e., you can have the core repo be a full-fledged project of
it's own if you want that doesn't a priori know or care about who's
using it.  I like this since I can do all of the automated testing,
extra tools, example code, etc.

Hope this helps,

More information about the Mercurial mailing list