[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