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

Satish Balay balay at mcs.anl.gov
Fri Nov 16 15:47:17 CST 2012


On Fri, 16 Nov 2012, Jed Brown wrote:

> On Fri, Nov 16, 2012 at 4:28 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > 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.
> >
> 
> Bookmarks are not required for this.

I guess you are refering to [petsc-dev,petsc-release,buildsystem] model with subrepo.

> I think it's pretty rare that someone
> outside of the core group needs to commit to release buildsystem after a
> release, but that can still be done without bookmarks. Just commit to the
> release point, then merge with tip, but do not advance petsc-release to
> point at tip.

the commit workflow issues are primarily for the core group. But there
will be workflow changes [wrt subrepo] for users who use petsc
[release or dev] from mercurial. [so we'll have to be prepared for
more email tarffic due to that]

Satish

> 
> 
> >
> > 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 :)]
> >
> 




More information about the petsc-dev mailing list