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.
Barry On Mar 24, 2011, at 5:11 PM, Jed Brown wrote: > On Fri, Mar 25, 2011 at 00:59, Satish Balay <balay at mcs.anl.gov> wrote: > I might be paraphrasing here - but Barry would like an 'equivalent' of > a single repo view [wrt commit, pull, push, location of invocation of hg] > > Here is the commit problem: > > If you commit from BuildSystem with PETSc not in the picture, then there is > no way for the PETSc repository to automatically know that it should pull the > most recent version. In order for PETSc to "know" which version of > BuildSystem is associated with a given version of PETSc, it has to store the > SHA1 somewhere. The implementation puts this in .hgsubstate. Of course, being > a version control system, this file is versioned. When you commit to > BuildSystem from inside PETSc, it updates this file and checks it into PETSc. > This way, external commits to BuildSystem are not visible to PETSc and you > can always "hg update" to an old version and know that the combination was > actually tested (assuming the committed version was tested). If the PETSc > repository did not store any .hgsubstate, there would be no way to keep track > of which version of BuildSystem was used when a certain version of PETSc was > tested. > > This is the closest thing to a single repository view that can actually be > robust if BuildSystem is ever modified externally (otherwise comparing dates > and hoping that everyone has a sufficiently calibrated clock and did not make > any mistakes could be viable). 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.
