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