<div dir="ltr"><div class="gmail_quote">On Fri, Mar 25, 2011 at 01:30, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
</div><br><div>This scheme is necessarily more fragile, but I admit that it may be convenient the way we use BuildSystem (which is basically as a part of PETSc). Who ever commits to BuildSystem without PETSc around? (It looks like nobody according to the history.) Is there harm in just always committing from petsc root instead of from "inside" BuildSystem? Then you could just pretend that there was only one repository. Maybe even add a BuildSystem commit hook to prevent accidental committing from inside when it is being used as part of PETSc.</div>
</div>