splitting a project tree

[Mathieu Lacage]

On Mon, 2008-03-10 at 13:19 -0800, John D. Mitchell wrote:

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

yes. I don't believe in the ABI compatibility of template-heavy C++ code
compiled with multiple versions of gcc and I can't see myself constraint
my users to use a single gcc version on a single platform (some crazy
users use cygwin :/)

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

thanks for the idea though,
Mathieu