-
Notifications
You must be signed in to change notification settings - Fork 11
NewRepoLayout
Large checkouts take ages. It's impossible to have hemelb without hemelb-input which is massive.
Pro: minimum faff from the current setup
Con: we want it to be easy to get to the tip of the hemelb repository - with this setup, that requires committing your changes in hemelb, then again in the outer repo. The alternative is that updating hemelb-input won't take you to tip of hemelb.
Pro: fully decouples repositories, we can take any combination of the repositories.
Con: Even more faff with committing hemelb and hemelb-input separately, and then committing hemelb-dev to keep tip pointing to the right place.
Solution 3: Keep the current structure and move to Git (http://book.git-scm.com/5_submodules.html)
Pro: It's possible to do this without losing any of the repo history and Git allows cloning a repository without taking submodules
Con: We've all got used to mercurial, and this one is almost certainly the biggest faff.
JH wonders: What about a solution similar to the current input-as-child solution, where hemelb-input is cloned/updated separately by a testing script in the main repo, rather than being a mercurial subrepo. Then it would be easy to get an optional clone of hemelb-input. (i.e. the do-regression-test script does an hg clone or pull/up if necessary, basically a cludged more usable version of subrepo).
JH comments: Of the above options, I favour 2, because although I do love git a lot, it would probably be too much of a faff to change.
HC: half a vote to each of solution 2 and solution 3.
JH: Votes for option 2, although in his heart of hearts he loves git.
RWN: 2