A few comments about the model and expectations [valid or invalid] [a] Barry's concers [latest buildsystem with latest petsc-dev] assumes no incompatible changes [to BuildSystem are pushed]. This assumtion is correct only if buildsystem chages are always done in sync with petsc-dev and always tested with petsc-dev - before pushed. In this case a single repo is the correct model. However Matt likes to keep BuildSystem separate to support potentially other projects. 2 cases here: [b] someone else [not using petsc] is making change to buildsystem and testing & commiting to BuildSystem. In this case - such changes can break petsc-dev - [so always latest changes as Barry would want- is the wrong thing here]. Here subrepo model [where Matt has a different master for BuildSystem and petsc-dev has its own subrep of buildsystem - and they get synced frequently] is appropriate. [c] Matt is the only person making fixes for the 'other projects' i.e all changes do get tested in petsc-dev context. In this again a single repo is the correct thing. The 'other project' users who need buildsystem [without petsc-dev] could get it with perhaps some auto-generated buildsystem-other repo - with perhaps some triggers [that does equivalent of 'bk csetprune' perhaps with hg convert'] Currently we are using [b] as the reason for split repo - but using the workflow from [c] - giving rise to expectations of [a] Satish On Thu, 24 Mar 2011, Barry Smith wrote:

My concern is simple. (1) Someone adds some fixes to BuildSystem, commits and pushes. (2) Someones uses PETSc with the BuildSystem subrepository does a pull in PETSc and NEVER gets the stuff that was put into BuildSystem. Given this I don't care how great it is that you can get consistent rollbacks and all kinds of good stuff by having a subrepository, nor do I care how hard it would be to get my model to work; this one flaw ruins all the great stuff you do get.

On Mar 24, 2011, at 5:11 PM, Jed Brown wrote:

...

To really have a single repository view without "redundant" commits to both BuildSystem and PETSc, and with some useful rollback semantics, you would have to really make one repository. As I understand it, Matt is rather opposed to directly importing BuildSystem into PETSc. I don't know how many people use BuildSystem without PETSc, there is certainly no backward-compatibility so it would be awfully hard to recommend.