On Sat, 17 Nov 2012, Satish Balay wrote: > On Fri, 16 Nov 2012, Barry Smith wrote: > > > > > On Nov 16, 2012, at 3:45 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > I think we could nicely do petsc-dev, petsc-release, and one buildsystem > > > managed as a subrepo. > > > > I'm willing to try this. > > So how do we proceed with it? > > - commit buildsystem as subrepo of petsc-release > - reset petsc-release/config/BuildSystem to point to bitbucket/buildsystem > - remove 'auto-clone buildsystem code from petsc-release > - fixup tarball generation code to work with subrepos > - merge with petsc-dev > - abandon buildsystem-release? > [more cleanup in petsc-dev] > - rename BuildSystem -> buildsystem in petsc-dev only? > > Do we make sure all commiters to petsc-release have the latest > mercurial? [even subrepo behavior can be different with older > mercurial versions..] > > And the workflow for release patches. > > - *never do* pull or update in petsc-release/config/BuildSystem > - commit change to petc-release [even if the change is in > petsc-release/config/BuildSystem] > - push petsc-release to bitbucket [but the subrepo buildsystem push will > fail?] > - merge petsc-release to petsc-dev > - [how does one merge petsc-release/BuildSystem*release-head* to > petsc-dev/buildsystem-*head*?] > - push petsc-dev to bitbucket [this should also push > petsc-dev/config/buildsystem with > all changes to bitbucket?]
Also how do we handle the following senario: with the current workflow - the following cold happen: - I fix something to buildsystem-release and push - Barry fixes something [with old buildsystem-release] and attempts to push - but push fails. - So Barry does a 'pull; merge; push' on buildsystem-release [at some point] either Barry or I can do buildsystem-release -> buildsystem-dev merge [once or multiple times] With subrepo what would be the workflow? Satish
