[petsc-dev] moab nightlybuild failure

Jed Brown jedbrown at mcs.anl.gov
Fri Jun 28 17:33:20 CDT 2013


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).  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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130628/7d0d2916/attachment.sig>


More information about the petsc-dev mailing list