[petsc-dev] Notification: Fwd: You have hereby been granted admin access to jedbrown/petsc-dev.

[Satish Balay]

On Fri, 16 Nov 2012, Dmitry Karpeev wrote:

> On Fri, Nov 16, 2012 at 3:06 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > On Fri, 16 Nov 2012, Jed Brown wrote:
> >
> > > On Fri, Nov 16, 2012 at 2:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > > >   In petsc-XXX/config/   what will you call BuildSystem?  BuildSystem,
> > > > buildsystem, buildsystem-dev, buildsystem-XXX
> > > >
> > > >    It would be nice to have totally consistent naming of the same
> > thing in
> > > > different places but do we really want petsc-XXX/config/buildsystem-yyy
> > > > where
> > > > yyy is different depending on release or dev?
> > > >
> > >
> > > If we used hg subrepo, each PETSc version would reference a SHA1 from
> > > buildsystem. Then we could just have buildsystem. When a patch needed to
> > go
> > > into "buildsystem-release", we would apply the patch to the buildsystem
> > > version that release depends on and update petsc-release to reference
> > that
> > > SHA1, independent of the existence of post-release patches (only relevant
> > > to petsc-dev) in the buildsystem repository.
> >
> > And the next step is to just have 'petsc' and 'buildsystem' repos [no
> > petsc-release] to fix a different inconsistancy [1 for buildsystem, 2
> > for petsc-dev]
> >
> +1

The complexity of this workflow is:

- should be comfortable with having multiple heads [atleast briefly -
if the history is to be similar to currrent workflow]

- be able to work with revs other than heads - I guess managed with
bookmarks [and commit changes] to such revs and keep switching back
and forth [between tip, bookmarks etc..]. And make sure everyone uses
latest mercurial - otherwise 'hg bookmark' behavior could be
different.

Its doable as long as folks are ok with the model.

Personally I'm more comfortable with 'a seperate repo to represent
each branch' and thats what I had been doing at petsc.cs.iit.edu [but
now I'm ok with a single petsc-release repo - as long as Jed handles
the case of simultaneous commits to multiple releases :)]

Satish

> 
> >
> > and then 'petsc' only [and no buildsystem]?
> >
> > Wrt your suggestion - I guess it would work at the cost of extra
> > complexity wrt workflow.
> >
> > Satish
> >
> 
> 
> 
>