splitting a project tree

Mathieu Lacage mathieu.lacage at sophia.inria.fr
Mon Mar 10 13:41:18 CDT 2008


hi,

We have been using quite successfully mercurial for more than a year now
(http://code.nsnam.org): our main development tree is the ns-3-dev tree.
Each of us maintains a set of clones in which we do our development and
then, we merge and push back our changes in the ns-3-dev tree when the
time comes. ns-3-dev is cloned to ns-3-xx.xx just after every release is
tagged.

Recently, we have started discussing splitting our tree in two
subprojects:
  - a 'core' project which would include our portable utility library
  - a 'model' project which would include all our network models

>From a release perspective, we want to release two tarballs:
  - a 'core' tarball which includes only the 'core' project.
  - a 'full' tarball which includes both the 'core' and 'model'
projects.

>From a developer perspective, we want to allow:
  - work on the 'core' project standalone. No impact on users of the
'model' project. 
  - Allow you to build a special mix of versions of 'core' + 'model' to
test the 'core' under development.
  - work on the 'model' project: there should be no need to pull a
separate 'core' project into the 'model' project to build it: it should
just automatically contain the currently working and tested version of
'core'.

I have looked at the forest extension to see if it would be useful to
us: although it seems that it might do the trick, I have been
underwhelmed by the UI (compared to the normal mercurial UI): I think I
could work with it myself but I have a hard time seeing all developers
deal with it to work on the 'model' project.

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.

I am not sure I have explained what I want to do very well but I would
be happy to hear feedback about the latter approach: limitations, big
problems I will run into, etc. If you have a better idea, I would be
happy to hear about it too :)

Mathieu



More information about the Mercurial mailing list