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.