[Users] [Commits] [svn:einsteintoolkit] TOVSolver/trunk/ (Rev. 137)

[Ian Hinder]

On 11 Jul 2013, at 17:21, Roland Haas <rhaas at tapir.caltech.edu> wrote:

> Hello all,
> 
>> Weren't these patches committed individually, which should make
>> Jenkins useful for finding out which of these broke things?
> I believe Jenkins only tracks on the granularity level of commits to the
> master git repository. Certainly the "failed since" link
> (https://build.barrywardell.net/job/EinsteinToolkitProposed/453/testReport/(root)/TwoPunctures/bhns_eval_1procs/)
> in the emails points to a comitt that incorporates multiple svn commits.

There are two issues here. The first is that several quick commits to the SVN repository will be collapsed into a single git super-repository commit, and the second is that Jenkins is only able to test the "current" state, it doesn't walk through each commit of the repository testing each one.

I added an option to create one commit per submodule commit in the super-repo to the git-module tool a while ago, but I'm not sure it is wise to use this option.  The problem is that it gives the impression that a particular super-repo commit represents a snapshot in time that actually existed, whereas that particular snapshot may never have existed.  For example, someone might have pushed a set of 10 commits in one go to a submodule repository (e.g. Carpet), with later commits fixing bugs identified in earlier commits.  The earlier commits were never the HEAD of the central repository, and might never have existed at the same time as the current version of other repositories.  It just wouldn't make sense to have a super-repo commit representing that state.  There is also the issue of having branching in the repositories.  Suppose the master branch in the sub repository diverges and converges (e.g. because you did a pull without rebase).  Which side of the branch do you test?  Both?  In the end, I decided that it made more sense to create one commit for each "snapshot" in time that was actually found as the current HEADs of all the sub repositories, and that is the current behaviour.

The ability to test every commit is just missing in Jenkins.  Probably it has not been widely requested by users because it is usually quite clear which of a small number of commits is responsible for a given breakage, and testing every commit might use too many resources.  It would be possible to hack something on top of Jenkins to achieve this.  On the other hand, developers should also be capable of running the tests themselves, and it's only a small number of commits which need testing here.

> It should should not be difficult to walk the list of commits and check
> where it fails though, I just don't have the time to do so right now.
> Certainly anyone who wants to give it a try is welcome. :-)

Weren't you the one who made the commits in the first place?  I think if you don't have time to fix them, you might not want to commit them… :p  Revert?

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130711/10a39e9d/attachment.bin