[petsc-dev] subrepositories

[Barry Smith]

  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.