On Tue, May 28, 2013 at 5:46 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> Hi,
>
> On Tue, May 28, 2013 at 3:26 PM, <dcerutti.rci.rutgers.edu> wrote:
> > This is why I
> > added the idea that each commit trigger one GNU compilation only, for
> > serial and parallel builds. This, I think, will catch 90% of the
> problems
>
> But developers should be doing this anyway before committing (as well
> as running the tests), especially with GNU compilers since everyone
> has access to them. Then the dashboard can catch other issues (like if
> the compile breaks with a compiler you don't have access to). One
> thing I like to do when I've made relatively large changes is I have a
> separate GIT directory (i.e. separate from the one I commit from) that
> I will update after I've made my changes and compile/test from there;
> this catches things that don't necessarily show up in the other
> directory (like if I forgot to 'git add' a file).
>
FWIW, I have a similar setup. One tree that is my 'working' branch and
another that is typically clean (via `git clean -fxd') so I can test from a
completely clean slate for large changes.
These repos are connected to one another, and I can push/pull between the
two repositories (on the same hard drive).
We don't really have that many developers pushing into a single
project/program right now (nowhere near 80 for any individual program). As
long as people run the necessary test cases* and are responsive when
informed that their commit broke something on another platform, I don't
really have legitimate complaints about the status quo (plus CC). I'm
guessing the inconvenience and setup overhead of any automated solution
will outweigh the inconvenience of the occasionally incomplete commit. And
as always, part of the glory of git is that all mistakes are reversible.
--Jason
*necessary being the key adjective here. Given the weight of the full test
suite, I sympathize running a targeted few to evaluate the affect of a
'small' change to a single program. If you take many shortcuts you'll
eventually be bitten by not running the full suite (we can all attest to
that, I'm sure), but it's unreasonable to require all commits to be
flawless in a project the size of Amber.
To quote the Zen of Python:
...
Now is better than never.
Although never is often better than *right* now.
...
> -Dan
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 201
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-9119 (Fax)
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue May 28 2013 - 18:30:02 PDT
