[petsc-dev] Updating MOAB version during download

[Satish Balay]

On Mon, 16 Jun 2014, Satish Balay wrote:

> On Mon, 16 Jun 2014, Barry Smith wrote:
> 
> >    When Vijay, or some one else doing something else says; hey Barry please take a look at my branch xyz and build it and test and add features a, b, c,  ALL THEY SHOULD NEED TO TELL ME IS branch xyz, I check it out and start building. If they need to tell me also get branch wyx of moab and branch abc of XYZ then we are NOT using tools efficiently (let’s just email the files back and forth). Each branch should have all the information needed to build for that branch, this simply means each branch has IN the appropriate xxxx.py package file the correct information about what other packages versions to use. This is actually easy except for 
> 
> Note: If I read this correctly you are not editing/fixing commiting to
> moab repo.
> 
> To me it looks like you are 'mercurial subrepo' workflow.  Perhaps an
> equivalent thing exists for git. Jed might chime in.
> 
> And yes you can get equivalent thing with 'xxxx.py:gitcommit=xyz' - if
> this is set correctly [not the gitcommit=branch/head thingy]. I think
> this is what Jed was also advocating..

I should modify this statement.

With hg-subrepo - one would do:

hg update [commitid] to get a consistant snapshot of petsc+moab

With 'xxxx.py:gitcommit=xyz' one would do:

git checkout [commit-id]
rm -rf arch*
./configure --download-moab=1

to get equivelent functionality [resulting in a git clone each time. This will presumably be
fixedup in the future]

Satish

> 
> >    merging to next and master where you may not want to drag along exactly the repository branch info that was used with the branch. (this relates to Vijay’s question).
> 
> Dragging  gitcommit=xyz to master is not a problem [draging gitcommit=head is a problem]
> 
> >    The tools manage the coordination, people don’t mange coordination with notes on scraps of paper and rumors in the hallway about what commit of moab they should use with what branch of petsc.
> 
> I agree one should use tools to simplify as much as possible. But configure should
> not  be the only tool that bears this burden. [to me workflow is partly a social
> contract between team members to co-ordinate in a predetermined way].
> 
> > 
> >    Jed has pointed out that a “branch” is not enough information, so what should we use in the xxx.py so that the correct thing is built when I build PETSc with a particular branch??? 
> 
> commit-id, tag.
> 
> Branch is also a 'tag' but its a moving tag - [with non-reproduceable
> state].  I think this is Jed's objection. [and mine as well [wrt
> gitcommit=master-head]
> 
> Satish
>