splitting a project tree
mathieu.lacage at sophia.inria.fr
Mon Mar 10 16:26:05 CDT 2008
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,
More information about the Mercurial