[petsc-dev] Updating MOAB version during download

Barry Smith bsmith at mcs.anl.gov
Mon Jun 16 17:47:54 CDT 2014


  How about the following model. When one makes a PETSc branch zzz that will 

A) use a frozen form of another package -- then moab.py (or AAA.py) points to either a release or a commit-hash

B) use another package that will be updated/fixed based on the work in the PETSc zzz branch. — then they
      1) make a branch xxx in that other package 
      2) make moab.py point to that branch xxx in the PETSc branch.

C) Note: moab.py (or AAA.py) can never point to master or next of moab. It can only point to a commit-hash or a development branch.

This will give me all the capabilities I want. 

  Jed, yes I know one cannot bisect back through the two branches together, but you can’t have everything. 

The only tricky time is when zzz gets merged into PETSc master or next. At that time presumably we want the merged moab.py to point to the commit-hash of the xxx branch in moab. Can this be automated, of course because anything can: if yyyy.py package points to a branch when merged into next or master (or any branch) the branch gets switched to the commit-hash of the head of the branch? Now translate to git language.

  Barry



On Jun 16, 2014, at 5:19 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Mon, 16 Jun 2014, Jed Brown wrote:
> 
>> Satish Balay <balay at mcs.anl.gov> writes:
>>> With hg-subrepo - one would do:
>>> 
>>> hg update [commitid] to get a consistant snapshot of petsc+moab
>> 
>> git submodule is similar, but it would be crazy to add every optional
>> external dependency as a submodule to petsc.git.
> 
> [I was thinking in terms of collabortive development petsc+moab - and
> not 'package-management' for users.]
> 
> So currently its 2 repos - in the future it could be more.
> 
> However 'submodule' is a new tool - so it needs learning. I don't know
> all caveats. [for eg: location of the submodule cause problems? Will
> the submodule always get cloned even if the user is not using it?
> Will all petsc git users have to be aware of submodule? git commands
> in subrepo behave differently than in petsc repo.. ]
> 
> Perhaps petsc configure:giturl [with --download-package] is preferable.
> 
> One difference though:
> 
> with submodule 'git commit' would probably automatically track the
> hashes between repos. But with configure:giturl - this has to be
> manually added to moab.py. Not a big deal..
> 
> [we would also have to fixup configure:giturl to do 'git fetch; git
> checkout commit-id' for each configure run..]
> 
> Satish




More information about the petsc-dev mailing list