On Fri, 8 Feb 2013, Sean Farley wrote: > > Satish Balay writes: > > > Barry/Jed/Sean, > > > > Should we have a recommended method of handling 'private branch' for > > petsc developemnt? > > > > thanks, > > Satish > > > > ---------- Forwarded message ---------- > > Date: Fri, 8 Feb 2013 16:24:46 -0600 (CST) > > From: Satish Balay <balay at mcs.anl.gov> > > To: Hong Zhang <hzhang at mcs.anl.gov> > > Subject: Re: private branch of petsc-dev > > > > There might be different ways of doing it with different tradeoffs > > with each method. > > > > Perhaps you might have to use bookmarks or something. I don't know > > enough about this. > > That would only be recommended if working in the same repo (e.g. > petsc/petsc-dev). > > > One way do this is [similar to the way we do petsc-dev/petsc-3.3 split > > work]: > > > > - have a separate petsc-dev clone somehwere as say petsc-dev-qlp. > > Sure, I would say just fork your own repo on bitbucket. > > > - you and Terrya will have a clone of this petsc-dev-qlp repo locally > > where new code gets added. > > > > - pull/merge from current petsc-dev to petsc-dev-qlp regularly [if > > this development has to be in sync with petsc-dev] > > > > - Only when everything is done/ready push from petsc-dev-qlp clone to > > petsc-dev > > > > The drawback here is - the history of this work would be messy [with > > all the merges etc..] > > > > The other way is: > > > > - have a separate petsc-dev clone somehwere as say petsc-dev-qlp. > > > > - you and Terrya will have a clone of this petsc-dev-qlp repo locally > > where new code gets added. > > > > - *never* sync with petsc-dev until this work is done. > > > > - merge with petsc-dev when its done. [either merge - or rebase it over] > > > > The *never* sync with petsc-dev is a drawback for this. > > You could just `hg pull --rebase`? Unless you mean don't push to > petsc-dev, then yes, don't push to petsc-dev until the feature is done.
'hg pull --rebase' would be great for a single developer of the feature. But with 2 developers commiting/communicating commits - one would have to 'strip out the old changes' - as you put it - either manually or with mercurial tools - and then propogate this to remote repo aswell. So its easy to make mistakes in the workflow? > If bitbucket would fix this issue, > > https://bitbucket.org/site/master/issue/4560/provide-a-method-for-setting-the-phase-of > > then you wouldn't have to strip out the old changes manually. If the remote repo is set to "non-publishing" - Would this feature strip out "old commits in the remote repo' on "hg push"? > Perhaps, I > could give a tutorial on this workflow to Hong and others sometime later > this semester? Or Jed will give a tutorial on Git :) Satish > > > Perhaps Sean/Jed will have better responses. [wrt bookmarks] > > Unfortunately, until bitbucket fixes the above issue, bookmarks wouldn't > help that much. > > > Satish > > > > On Fri, 8 Feb 2013, Hong Zhang wrote: > > > >> Satish, > >> How to create a private branch of petsc-dev for me and > >> Sou-Cheng (Terrya) Choi to develop new KSP miners-qlp? > >> > >> Should I use 'hg branch'? > >> I tested, but got trouble on how to merge the branch back > >> to the default repo. > > Erase the command `hg branch` from your vocabulary. >
