<div class="gmail_quote">On Wed, Jun 6, 2012 at 6:41 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">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">
<div class="im">> $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise how would you know it's there<br>
<br>
</div> Stop right there. So you are saying if I just run in petsc-dev: hg pull -u it will NOT pull and update in BuildSystem?<br></blockquote><div><br></div><div>It will pull up to the last revision of BuildSystem that has been marked. If someone goes off and updates BuildSystem externally, it will not automatically pull that. But I assert that you don't actually want that. If it was actually updated externally (like anything that is legitimately a different project), *some* petsc developer should be certifying that new revision is correct.</div>
<div><br></div><div>Of course this step is not needed if we are making the update in tree. In that case, you just commit and push from petsc and the buildsystem commits will be done for you.</div><div><br></div><div>Specifically</div>
<div><br></div><div>~/petsc-dev$ emacs config/BuildSystem/config/framework/config/framework.py</div><div>~/petsc-dev$ hg commit --subrepos -m'framing work' # commits in both config/BuildSystem and petsc-dev</div><div>
<br></div><div>You can use -S = --subrepos or add it to your alias.</div><div><br></div><div>An alternative:</div><div><br></div><div>~/petsc-dev$ hg -R config/BuildSystem commit -m"Add something to buildsystem, but don't publish to petsc-dev"</div>
<div>... do other things in petsc-dev, maybe update something dependent</div><div>~/petsc-dev$ hg commit -m"Add thing that depends on buildsystem's 'something' patch, but has a different commit message"</div>
<div><br></div><div>This second commit will include the new .hgsubstate. It will be pushed and pulled automatically.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What if in petsc-dev I do: hg commit; hg push. Will that or will that not commit and push all the changes I made in the BuildSystem ? Or will it ignore the changes I made in BuildSystem? Or will it put those changes into the petsc-dev repository and not the BuildSystem repository (so Matt won't get my cool changes I made to BuildSystem)?<br>
</blockquote><div><br></div><div>Something in config/BuildSystem will never go into the petsc-dev repository, always the BuildSystem repository.</div><div><br></div><div>Your pulls and pushes are recursive by default. If you want commit to be recursive by default (instead of needing the -S flag to recurse into subrepos), you can set that in your .hgrc. If you make -S default, it will still only make a BuildSystem commit if something changed there, so it's relatively harmless (as long as you want to use the same commit message for a fix to BuildSystem as for the dependent patch in petsc-dev).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What if I am in the BuildSystem directory and commit and push? Into what repository(ies) do my changes go? Does it matter what directory I am in what happens when I do hg commit etc?<br></blockquote><div><br></div><div>
If you are in the BuildSystem directory, then you are working with the BuildSystem repo independently from PETSc. The next time you commit from the PETSc repo, it will sync up with the last commit visible in config/BuildSystem.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think Satish proved a few months ago the subrep concept made no sense with our petsc-dev and BuildSystem workflows. So why are you guys revisiting it since you haven't improved the inadequate subrep model since then?<br>
<br>
Please explain our work flow under the subrepo model where any of us are making changes in petsc-dev and BuildSystem (as part of petsc-dev) meanwhile people may also be making changes to BuildSystem.<br></blockquote><div>
<br></div><div>In normal workflow, you can just always commit with the -S switch (even add it to your .hgrc) from the PETSc repository. It will automatically include a commit to BuildSystem when it's necessary and will always be synced.</div>
<div><br></div><div>If you make some BuildSystem commits while someone pushes their own upstream without touching the petsc repository, your push will be rejected (just like with any repository) and you should pull the updates for BuildSystem, merge, and commit.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Note: don't think I am opposed to resolving the bisection problem, I am just opposed to "fixing it" if it totally breaks our everyday work flows.</blockquote></div><br>