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.
