[petsc-dev] moab nightlybuild failure

[Barry Smith]

On Jun 28, 2013, at 5:53 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Fri, 28 Jun 2013, Jed Brown wrote:
> 
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>> 
>>>> petsc-branch:moab.py could name a commit on a MOAB branch, possibly
>>>> updated on merge.
>>> 
>>>   otherwise it is hopeless.  So each PETSc branch would have to have
>>>   in it somewhere information about which MOAB "branch/commit" it is
>>>   suppose to use and switching to (checking out) that PETSc branch
>>>   means it will automatically switch to that moab branch (oh sorry,
>>>   "checkout" to that moab branch).  In addition when the PETSc branch
>>>   is merged to another branch the right information about the moab
>>>   commit/branch that should be used needs to be put in the right
>>>   places in that merged branch. Can you do this? 
>> 
>> This is why MOAB has its own test suite.  A working branch can appear in
>> PETSc while some work is being done in moab.  During that time,
>> gitcommit can be set to point at the MOAB commit (could use a branch
>> name here, but then it won't work later when that branch has been
>> deleted; a commit is better because it's precise and eternal).
> 
> Not if the branch is rebased [and later garbage collected] - which can
> happen with all working brances [but not master/maint]
> 
> Satish

   I think the gitcommit business should ONLY be used when moab master is ahead of petsc master (for example Tim totally redesigned the moab API but hadn't gotten around to updating PETSc talking to it). gitmaster has no role to play in dealing with the co-design development of PETSc and MOAB in synchronized branches (which Jed claims is too hard to automate and I am fine with manually matching the branches).

   Barry

Hence the gitcommit is always something in master and hence eternal.




> 
>> This is
>> basically the same model as git submodules and hg subrepos.  Merges are
>> still tricky because they need out-of-band information and may not be
>> achievable (if the branches containing the two commits have not been
>> merged in MOAB).
>> 
>>>   Surely git must have some unforgivably clumsy syntax somewhere to
>>>   allow branches in two repositories to always meet their correct
>>>   partners that the dance?
>> 
>> I think the semantics you desire are nebulous to define in the general
>> case.  It's a very complicated workflow and I think quite unnecessary.
>> 
>