[petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
jedbrown at mcs.anl.gov
Wed Jun 6 21:15:16 CDT 2012
On Wed, Jun 6, 2012 at 6:41 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise
> how would you know it's there
> 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?
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.
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.
~/petsc-dev$ emacs config/BuildSystem/config/framework/config/framework.py
~/petsc-dev$ hg commit --subrepos -m'framing work' # commits in both
config/BuildSystem and petsc-dev
You can use -S = --subrepos or add it to your alias.
~/petsc-dev$ hg -R config/BuildSystem commit -m"Add something to
buildsystem, but don't publish to petsc-dev"
... do other things in petsc-dev, maybe update something dependent
~/petsc-dev$ hg commit -m"Add thing that depends on buildsystem's
'something' patch, but has a different commit message"
This second commit will include the new .hgsubstate. It will be pushed and
> 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)?
Something in config/BuildSystem will never go into the petsc-dev
repository, always the BuildSystem repository.
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).
> 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?
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
> 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
> 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.
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.
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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the petsc-dev