[petsc-dev] private branch of petsc-dev (fwd)

[Satish Balay]

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.
>