[IMP-dev] One final attempt to stir discussion before I give up on IMP svn
To: "IMP developers' list" <>
Subject: [IMP-dev] One final attempt to stir discussion before I give up on IMP svn
From: Daniel Russel <>
Date: Wed, 20 Aug 2008 10:15:37 -0700
Reply-to: List for IMP development <>
The current IMP rcs setup is completely idiotic. As a result, in order
to be able to actually track the changes I make to the IMP kernel I have
to maintain my own fork and then move patches back to the main svn. I am
tired of doing this and am somewhat inclined just to maintain my own
(public) fork and forget about contributing back to the main IMP svn. As
there are occasionally a few global changes, reconciling things will get
increasingly hard over time.
Restricting who can commit to svn offers no benefits over open submissions.
- code review as it now stands appears to simply consist of checking
formatting of the source files. Such can changes can be more easily done
as a modification of already checked in code. That would have the added
advantage of not having svn report everything as a conflict (svn gets
confused by my changes being committed from another working copy).
- No one is counting on IMP svn being constantly in a working state.
People wait to check things out until they know they have some time to
clean things up. As a result, there the invariant that all versions of
the repository work doesn't buy us anything over ensuring that it works
almost all of the time. The latter would make it easier to submit
patches since you don't have to ensure all files are submitted at once
and you can more easily check that your patch is OK by checking IMP out
and building it. Unless the automatic test scripts for IMP are a mess it
should be easy enough to have them create a "last stable" branch in svn
upon successful completion of the tests.
- svn is a revision control system. It allows us to roll back changes we
don't like after they are committed. That is the point.
And the current system has many disadvantages:
- submitting patches takes a reasonable amount of effort. As a result
minor changes to documentation and things which result in IMP overall
being a nicer experience never get submitted. In addition, it makes
people wait longer to submit things making the eventually submission
that much more complicated and reviewing of changes that much more involved.
- since it can take days (sometimes weeks if Ben is away) to get even
the simplest patches committed, it takes a lot of work to make focused
patches. Our time is better spent elsewhere.
- IMP is supposed to be a collaborative effort. It is hard enough to get
people to share their code without added hurdles. As it is, I seem to be
the only one inclined to go through the effort.
- we can't actually use svn as a revision control system. If everything
in in sync most of the time, then once can easily try speculative
changes and then revert them if they don't work. Since I can't do this,
I have to maintain my own svn repository with a copy of IMP.
- we don't have any easy record of who last changed each file without
reading the whole log making it harder to know who to ask about changes
Creating yet another project in IMP svn doesn't solve these problems and
results in another complication for people who want to use IMP since
they always have to think about which library to get it from/which
namespace to use.