[petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash

[Satish Balay]

On Wed, 6 Jun 2012, Jed Brown wrote:

> 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?
> >

Just want to clarify the 'subrepo' model:

subrepo is not emulating 'a single repo' usage with multiple repos.
[single repo model is best done with a single repo :)]

Subrepo model is letting us track other repos [i.e subrepo] changes in
the primary repo commits.  [similar to how file changes are tracked in
the primary repo commits].

However the difference is: file changes are registered as 'diffs' in
the primary repo commits. The 'subrepo' changes are registered as a
'primary-repo-commit-id -> sub-repo-commit-id' relations in the
.hgsubstate file in the primary-repo.

Some hg commands can use this info to act on both repos. Others dont.

Satish

> 
> 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.
> 
> Specifically
> 
> ~/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.
> 
> An alternative:
> 
> ~/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
> pulled automatically.
> 
> 
> 
> >
> >   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
> config/BuildSystem.
> 
> 
> >
> >   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?
> >
> >   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.
>