Subversive Story— Polarion Celebrates 8th Birthday of its Subversive Open-Source Project (1 of 3)
The story of the Subversive project begins in 2005, when Polarion assigned a development team to work on the open-source Eclipse client for Subversion (SVN). In the following years, Subversive changed from a new and almost unknown open-source project to one of the most popular plug-ins for Eclipse. Celebrating the 8th birthday of Subversive, we had the opportunity to talk about the project with Igor Vinnykov, who led Subversive from its early days.
What is the origin of the Subversive project? How was the idea to create an Eclipse client for SVN born?
Source: Google Trends
In 2005, companies and organizations started to actively migrate their source code repositories from CVS to SVN. SVN became a stable technology that offered a number of advantages compared to CVS, so Polarion selected SVN to become a core infrastructure component for the business. We stored all of our projects in SVN repositories and worked on our ALM tool and other products, which were integrated with SVN. Our main development platform was Eclipse, which was lacking quality integration with SVN source code repositories back in the day.
We tried different available solutions but came to use a standalone Tortoise SVN tool to work with SVN repositories. It was quite ineffective for our team to continuously switch between Eclipse and Tortoise SVN. We used Eclipse CVS client in the past and loved the functionality of CVS integration created by Eclipse developers. By starting the Subversive project, our goal was to provide Eclipse users with the quality SVN client inspired by Eclipse CVS client concepts.
Did you consider an idea to join forces with the Subclipse team?
In 2005, Subclipse was a single available Eclipse client for SVN and, of course, we tried to use it in our development environment. It offered almost all the features available in SVN during that time, but as Eclipse users, we weren’t satisfied with it. There were a number of bugs, and the Subclipse user interface was far from the polished UI we were used to seeing in the CVS client. We had an idea to fix the most annoying bugs and improve the Subclipse UI, but after spending a couple of weeks on the Subclipse code analysis, we concluded that our vision was different from the approaches used in Subclipse at that time. And so the Subversive project was born.
I know that there are some people who think that it was a mistake to start another project instead of joining forces with Subclipse, but it often happens that different people or teams have a different vision about the same things. For example, there are multiple open-source development platforms, databases, libraries, and SVN clients, which were created to perform the same job but ended up being used for different approaches. It’s the reason why we have a diversity of choices nowadays, and I think that it’s good. With no doubt, some kind of competition helped both the Subclipse and Subversive project to evolve to their current levels.
When was it decided to make Subversive an open-source project?
Subversive was created as an open-source project since the beginning because other infrastructure components such as Eclipse, SVN, and SVN libraries were open-source projects as well. So it was the obvious step to create a SVN client for Eclipse as an open-source project. We started development in the internal repository and opened it several months later once the first public version of Subversive was rolled out. A few years later, we decided that moving Subversive under the Eclipse umbrella would help the project, and so since 2007, Subversive has its home at the eclipse.org site. However, the project is still developed and supported by the same team of Polarion developers who started the project.
Was it hard to start a new open-source project?
It was a new experience for our team. The most complicated thing was to find support in the SVN user community. On the one hand, we wanted to release the first version as soon as possible, so our efforts would be appreciated by users for whom the project was created. On the other hand, we understood that a lot of functionality would be missing in the first release, and our first impression to the community could turn out negative because of this. Therefore, we had to find a compromise between an early first release date and missing functionality in the first version.
How did you find that compromise?
In 2005, when we started the project, SVN already had a long list of features. To implement them all in the Eclipse client, we would have needed to spend over a year and a half working on an isolated project without long-term communication with the community. In addition, we understood that our project was in demand, and so we decided to implement only the critical features and leave the rest to the next iterations.
We started to create the code in the SVN repository and used Tortoise SVN to work with the repository. Once we implemented and updated features, we thought that it was the right time to start using Subversive by ourselves to check how it works in the real work environment. It was one of the most important steps for the project because in the beginning, we found several important problems that weren’t detected during the testing sessions and started to look at the project not only as developers, but as users. These first weeks gave us a fresh vision, and we quickly found features that were missing or required improvements.
Then we asked our Polarion colleagues to start using Subversive in their day-to-day work, and it was another breath of fresh air into the project. Polarion used Subversive and – of course – Polarion ALM in all development projects from the beginning. That’s the important point- receiving feedback from your own team is crucial, who can be your first users. Sometimes, it works even better than the traditional testing because you not only have test reports, but you also get information on how to improve the project. By using this approach, we reduced the time-to-release of the first version and were confident that the main features were stable in the release.
There was another point that we had to resolve before making the first release – how to awaken community interest in our project. In my opinion, Eclipse IDE is one of the excellent examples of the stylish, usable and well-designed user interface. In 2005, there was a big contrast of the polished UI of components created as part of the Eclipse IDE and UI of external plug-ins. Our goal was to fill this gap and create a plug-in that would not only be usable, but would also follow all the UI design concepts and be considered an integral part of Eclipse. We wanted to give SVN users the same level of comfort that CVS users had in Eclipse and simplify migration from CVS to SVN by creating an SVN UI similar to the CVS UI. But this wasn’t blind copying- it was a deliberate choice and our bet on the future of our project.
Stay tuned for the next post!
