+1 for using branches : branch usage is less error prone plus git makes
branching unexpensive.
as far as i am concerned, i'd rather have the default master branch is
the for the "stable" version
and have one branch called devel (or dev, or whatever) :
- git clone => get the stable (aka master) bra
ore work/steps
>> to follow, and therefore more error-prone.
>>
>> 6. The point about not being able to automate getting the latest stable MTT
>> is a good one. How about using numerical tags just to delineate our
>> intended "release" points, but also have a
Folks,
i noticed that the bend-rsh cluster (Ralph from Intel ?) does not report :
- bitness
- endian
- compiler
- compiler version
- configure arguments
- vpath mode (to be confirmed)
i believe the root cause is MPI is not built via mtt since the
AlreadyInstalled module is used.
bitness can be
My 0.02 US$
An other approach would be to run the MTT tests, store the results in a
(text ? xml ?) file,
and then submit them from an internet connected machine.
not only that would allow you to submit to multiple databases, but that
would allow you to run
the MTT test suite on an cluste
Howard,
each commits trigger a travis build, and the deploy section of travis
builds the doc and push it if the html has changed
(the pdf contains timestamps, that's why we only focus on the html).
bottom line, the doc will be updated to gh-pages only if it has to.
If the gh-pages repo is
