[petsc-dev] moab nightlybuild failure
Satish Balay
balay at mcs.anl.gov
Fri Jun 28 17:53:55 CDT 2013
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
> 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.
>
More information about the petsc-dev
mailing list