At the imp-dev meeting yesterday, the question of switching to git from svn was raised. The hope is that it would facilitate having more frequent mini-releases of IMP (monthly being a target) as it makes it much easier to maintain parallel development threads. The main advantage of git over svn is that it makes it very easy to make and maintain branches since one can merge branches repeatedly without problems. As an illustration, someone who is making a major change to a module that would take a while to implement could create a new branch in the repository for the change, lets call it distance_functions. While distance_functions is being developed, any changes made to the IMP main branch can be easy pulled into the distance_functions branch simply by doing "git rebase" (doing this is very painful with svn) allowing the two to keep in better sync. And when the change is done, it can be brought back into the main development trunk without complication (and done more than once if so desired).
This change would also makes dealing with releases much simpler as a release simply means pulling changes from the main development trunk into a release branch and adding a tag. Any fixes we want to make to release can be easily done in a hotfix branch and then directly brought into both the release and the main development trunk, rather than having to be manually pulled into both places as with svn.
At the meeting, a reasonably fraction of the people were already using git for other projects (and I'm using it instead of svn for accessing IMP). So learning it does not seem to be an insurmountable hurdlw
I would also suggest we check out git flow. It defines a standard branch structure that supports releases, hotfixes to releases, feature development branches etc and provides scripts to aid in doing basic tasks. It is available on home brew, but there does not seem to be a standard rpm for fedora. Boost appears to be moving towards using it, among other projects.
We can provide some kind of support for existing svn users (probably read-only). This may simply involve using git-svn to sync to the git head and push it to the existing svn repository.
On 06/14/2012 09:54 AM, Daniel Russel wrote: > At the imp-dev meeting yesterday, the question of switching to git > from svn was raised. The hope is that it would facilitate having more > frequent mini-releases of IMP (monthly being a target) as it makes it > much easier to maintain parallel development threads.
We already committed to 6 month releases for the upcoming funding period. Personally I think every month is too frequent for anything but minor bug fixes, but we'll see how it plays out. I'll look into git, but I'd rather get a stable release out the door before any major infrastructural changes (MultiFit is the blocker here, of course, but all the major hurdles are out of the way there now).
Ben
Makes sense to get the next release out the door before any big changes, assuming that will happen in the next couple of months. I don't think every 6 months is frequent enough to solve the main problem regarding people who only update IMP infrequently. Not so much due to the period per se, but rather the latency, since their updates tend to be driven by needing some new feature and with a 6 month release cycle, that means waiting 3 months on average.
I also think, with a git-flow type of setup and with the infrastructure Ben setup for nightly builds, releases should become close to free. That is, all unstable stuff should be in a separate branch, so it is just taking the main branch and rebasing the release branch off of it. And no significant cleanup needed.
On Jun 14, 2012, at 10:02 AM, Ben Webb wrote:
> On 06/14/2012 09:54 AM, Daniel Russel wrote: >> At the imp-dev meeting yesterday, the question of switching to git >> from svn was raised. The hope is that it would facilitate having more >> frequent mini-releases of IMP (monthly being a target) as it makes it >> much easier to maintain parallel development threads. > > We already committed to 6 month releases for the upcoming funding period. Personally I think every month is too frequent for anything but minor bug fixes, but we'll see how it plays out. I'll look into git, but I'd rather get a stable release out the door before any major infrastructural changes (MultiFit is the blocker here, of course, but all the major hurdles are out of the way there now). > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Just to add, I think the main advantage of git for us is that it would decouple use of revision control and sharing of your code with others from committing to the main IMP source code.
To experiment with git and IMP some more, I'll set up a copy of the IMP repository on github and route my changes through that. Anyone who is interested in using it should let me know.
On Thu, Jun 14, 2012 at 10:39 AM, Daniel Russel drussel@gmail.com wrote:
> Makes sense to get the next release out the door before any big changes, > assuming that will happen in the next couple of months. I don't think every > 6 months is frequent enough to solve the main problem regarding people who > only update IMP infrequently. Not so much due to the period per se, but > rather the latency, since their updates tend to be driven by needing some > new feature and with a 6 month release cycle, that means waiting 3 months > on average. > > I also think, with a git-flow type of setup and with the infrastructure > Ben setup for nightly builds, releases should become close to free. That > is, all unstable stuff should be in a separate branch, so it is just taking > the main branch and rebasing the release branch off of it. And no > significant cleanup needed. > > On Jun 14, 2012, at 10:02 AM, Ben Webb wrote: > > > On 06/14/2012 09:54 AM, Daniel Russel wrote: > >> At the imp-dev meeting yesterday, the question of switching to git > >> from svn was raised. The hope is that it would facilitate having more > >> frequent mini-releases of IMP (monthly being a target) as it makes it > >> much easier to maintain parallel development threads. > > > > We already committed to 6 month releases for the upcoming funding > period. Personally I think every month is too frequent for anything but > minor bug fixes, but we'll see how it plays out. I'll look into git, but > I'd rather get a stable release out the door before any major > infrastructural changes (MultiFit is the blocker here, of course, but all > the major hurdles are out of the way there now). > > > > Ben > > -- > > ben@salilab.org http://salilab.org/~ben/ > > "It is a capital mistake to theorize before one has data." > > - Sir Arthur Conan Doyle > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > >
-
Ben Webb -
Daniel Russel