<div class="gmail_extra">On Fri, Nov 16, 2012 at 4:28 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ps">The complexity of this workflow is:<br>
<br>
- should be comfortable with having multiple heads [atleast briefly -<br>
if the history is to be similar to currrent workflow]<br>
<br>
- be able to work with revs other than heads - I guess managed with<br>
bookmarks [and commit changes] to such revs and keep switching back<br>
and forth [between tip, bookmarks etc..]. And make sure everyone uses<br>
latest mercurial - otherwise 'hg bookmark' behavior could be<br>
different.<br></div></blockquote><div><br></div><div>Bookmarks are not required for this. 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1ps">
<br>
Its doable as long as folks are ok with the model.<br>
<br>
Personally I'm more comfortable with 'a seperate repo to represent<br>
each branch' and thats what I had been doing at <a href="http://petsc.cs.iit.edu" target="_blank">petsc.cs.iit.edu</a> [but<br>
now I'm ok with a single petsc-release repo - as long as Jed handles<br>
the case of simultaneous commits to multiple releases :)]</div></blockquote></div><br></div>