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.
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 …
[View More]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?
[View Less]
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
…
[View More]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
[View Less]
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 …
[View More]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?
[View Less]