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