[IMP-dev] One final attempt to stir discussion before I give up on IMP svn

[Daniel Russel <>]

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 
and breakages.


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.