Subversive Story—Continued (2 of 3)
This is part two of a three-part series discussing the story of Polarion’s Subversive Project. Celebrating the 8th birthday of Subversive, we had the opportunity to talk about the project with Igor Vinnykov, who led Subversive from its inception.
How did you launch the first version of Subversive?
We didn’t do anything special – just created a webpage where people can download Subversive and sent announcements to several Eclipse and SVN-related online issues. Since the beginning, the SVN community showed interest in this topic, and we received a growing number of downloads. It was important to build good communication with the community, so we launched a forum where project members and community activists can answer the questions about Subversive.
Another good communication channel was based on using automatic error reports. We created a special error handler in Subversive that, in case of a problem, displayed the dialog where a user can enter comments and their contact information when reporting a problem. The user can submit the error report that automatically creates a bug on our bug tracker with the data entered by them and the Java stack trace that identifies the reason of the problem. We were impressed by the effectiveness of this new communication channel because once we launched it, we started to receive more feedback than before. If we had a bug in a release, we got error reports in minutes and didn’t have to wait days until somebody found some free time to write about the problem in the forum. It’s also helpful to get the contact information of people reporting the problems because we can contact them directly to get details or ask them to try a code patch. Many of the problem reporters were nicely surprised to get personal replies from us and gladly helped us with troubleshooting.
What was the first feedback on Subversive like?
People like new things, and many Eclipse and SVN users gave Subversive a try. We tried to differentiate the project since the first release, and I think that our bet worked well. From the start, people discussed the advantages and disadvantages of two SVN plug-ins for Eclipse. At that point, we understood that we had our own community, and there were a lot of people who like what we do. In the first release, we couldn’t offer support on all of the existing SVN features, but in addition to the polished UI, we had some other things to offer to Subversive users. When we started to work on Subversive, we understood that it would be hard to implement quality UI because some important features were missing in the SVN interface. For example, if you ran a long SVN operation, you didn’t get the information about its progress and couldn’t cancel it. We discussed these limitations with the authors of SVNKit library, the library we use to communicate with SVN repositories, and asked them to implement progress reporting and operation cancellation as an extension to standard SVN interfaces. As a result, Subversive offered some extra features that people expected to see and couldn’t find in other tools, so the first feedback we received was good enough to move us forward.
What was your main priority after releasing the first version?
We had very busy days after the first release. In spite of the fact that Subversive was used for day-to-day work internally, we received quite a lot of bug reports during the first few weeks. In Polarion, we just had several repositories and the limited number of developers who used the project in a similar manner. When the project went to the wild life, the number of use cases and environments used to work with Subversive grew significantly, so hidden errors started to appear quite often. It’s a normal situation for every project, so the only thing that is required from the development team, in this case, is to resolve the problems as quickly as possible. We had to make several releases one-by-one to resolve the most frequent and important problems. When the number of error reports decreased, we returned back to our plans and started to work on the remaining SVN features.
In 2006, you submitted a proposal to move Subversive under the Eclipse umbrella. What were the reasons for that step?
In July 2006, we released Subversive version 1.0 that supported the full set of SVN features. The project was considered a mature project, and we needed to define the new goals to move forward. SVN users wanted to get a preinstalled SVN client in Eclipse, the same as CVS users get when they install Eclipse, and Eclipse Foundation had interest in this topic. Also, our users asked us to implement integration with other Eclipse tools like Mylar (now Mylyn) and Buckminster, so the project migration to Eclipse and Subversive integration into Eclipse was the expected step.
What was required from Subversive to move it to Eclipse?
Project migration was a pretty complicated process defined by various rules and guidelines explained in the different documents of Eclipse Foundation. The most time-consuming part of the process was finding all of the required information and understanding the requirements and steps that should be performed. It took up a bunch of my time, so if you plan to create an Eclipse project, you have to be ready to perform some extra work and some paperwork as well. Someone called it a bureaucracy because you need to work with the formal papers instead of working on the project code, but you need to keep in mind that Eclipse joins hundreds of projects managed by hundreds of people from different organizations together, so defining and checking guidelines is the instrument that helps to avoid chaos. I have to say that in the past couple of years, the number of formal Eclipse procedures has continuously decreased, making developers’ lives easier.
In order to join Eclipse, we created the written Eclipse project proposal that explained our vision. We defined our goals and project principles, represented the project architecture, and defined the interested parties who supported the project and our development plan. After the publishing of this proposal, it was openly discussed in the community. There was another Eclipse project proposal from the Subclipse team, and Eclipse Foundation suggested that we consider merging our two projects into a single one. There were some negotiations around this topic, but the Subclipse team decided to revoke their proposal and not move their project to Eclipse, so our proposal was accepted by Eclipse Foundation at the end.
The conclusion to Subversive’s story is coming up soon!
