IMP-dev December 2011

imp-dev@salilab.org

3 participants
4 discussions

Improved nightly build results
by Daniel Russel 16 Dec '11

16 Dec '11

The nightly build page is much less used than it should be (I don't think anyone other than Ben or I looks at it regularly). This is, in part, I think because it is hard to extract the useful information from it. As i think it would be really nice to have more people looking at it after they submit changes and be able to get the information they want out more easily, I started a wiki page on ideas for improvement < https://salilab.org/imp/wiki/nightly>. Please add/change ideas.

1 0

No more IMP releases?
by Daniel Russel 16 Dec '11

16 Dec '11

Now that Ben has made the nightly builds available online it might make sense to move away from our current nominally release based distribution model to one based on just making the actively developed version of IMP more readily available. To make it clearer what I mean, the model would look something like: - some set of current and historical nightly test results are publicly available on line such that one can - check how the nightly tests went for a given night - if they were satisfactory, easily update your svn to that version or download the corresponding pre-built binary - large rearrangements of modules should be preformed by creating a new module (eg domino2 or multifit2) and working on that new module then merging the changes back in to the main module (or replacing it wholesale). - we perhaps include a periodically updated pointer to a stable version to use for people who don't want to think too much about it Basically, this is a formalization of what we are already doing, with a few extra features: - multiple versions of the nightly builds available - saving of the nightly test results - moving of the svn version associated with the nightly test results to a more prominent place in the page - links from the nightly test results to the corresponding downloads - a link somewhere to one of the nightly build pages as the current "stable" version (and, perhaps, a corresponding svn tag so that someone can fetch it from svn without thinking too much) Good? Bad? Scary?

3 9

Using git as an svn client
by Daniel Russel 09 Dec '11

09 Dec '11

I've been using git as my svn client for a few weeks now and can quite recommend it for anyone who is - writing large amounts of for IMP or an IMP module that is shared with others - writing code that sits in modules but is not committed back to svn for long periods The advantages of using git as your svn client instead of straight svn include - you can commit files locally (without sending them to the SVN repository) so that you have backups and tracking of your changes without subjecting everyone to them. For example, if you add a new class to the ISD module and have it in a working state, you can commit locally. Then if you make some changes that break something, you can see what the changes are and roll back if needed. Similarly, you can locally branch. - you selectively commit some of your changes, even when several changes touch the same file. You just have to commit the file with the first set of changes and then are free to make another set to the same file. - git does much better merging than svn, so it handles cases like sending patches back and forth between people with aplomb - moving around in the imp history is very fast with git, so if an update isn't happy, going back to the previous version is trivial and fast. If anyone is interested, a doc on how to get started can be found here: < http://maymay.net/blog/2009/02/24/how-to-use-git-svn-as-the-only-subversion… > As a few comments: - the first fetching of the files from svn takes quite a long time (an hour or so) - amazingly, the resulting checkout is significantly smaller than an svn checkout despite containing the complete history of the svn project

1 0

Moving display up in the world
by Daniel Russel 01 Dec '11

01 Dec '11

I'd like to move the display module up so that core and atom depend on it (rather than vice versa). This will have various nice effects such as - algebra and kernel tests that use display don't require building almost all of IMP - display can be used in core and atom C++ code to aid in debugging - code to display various decorators goes with the decorators - display now looks like statistics and algebra in that it provides low level services that can be used by many other modules The externally visible breaking change caused by this will be that various display::Geometry subclasses for displaying decorators will be moved to other modules. Specifically: IMP::display::XYZRGeometry will move to core IMP::display::HierarchyGeometry will move to atom IMP::display::SelectionGeometry will move to atom Objections, comments?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev December 2011