When version control systems fail miserably

When I began using version control system software, the world was mostly stuck with RCS, if you wanted to use free software that is. Next came CVS, PRCS, SVN (Subversion), Bazaar, Git, Mercurial, and many others. There were, of course, also many commercial version control systems available such as ClearCase and Perforce. So now we have several excellent pieces of software when it comes to version control.

In most cases, users of these version control systems seem to fall into two categories. Those that prefer to work locally on their own machine or in their own environment, and those that work in a shared environment. Regardless of which category you fall into, the theory behind many modern version control systems is that you never work against the immediate source, but instead use some sort of local version, be it “working copy” or “cloned repository”.

With the advent of integrated development environments such as Eclipse and Netbeans (and many others), support for version control systems is often built-in or provided via some plugin. You get immediate notifications when your source files have been modified (by yourself), when a conflict occurs, you can check files in and out of the repository, etc.

I — and others — seem to have run into a problem with the way things are being done, and I cannot seem to find a solution to this problem, other than resorting to the command-line interface of the various tools (svn, hg, git, etc).

Here’s my beef:

I keep a stable, production level, copy of a project at /home/prod/stable. It is reachable from the web (because that’s where I use the application) as http://www.somewhere.com/prod. It is also under version control at /home/repo/prod[..]

Now, I also keep my development version on that same server, also reachable from the web (because I don’t think duplicating my runtime environment on every single computer I may work on the project from is a grand idea). So for this, I have /home/prod/dev and http://www.somewhere.com/dev; I can choose to have a complete “duplicate” repository at say /home/repo/branches/dev, or just a working copy at /home/prod/dev. The crucial issue here is that I keep my live development files on the same server as the repo, but I code using NetBeans or Eclipse (or anything based on Eclipse) from my laptop or one of my workstations.

This combination seems impossible to get working if I want to use the built-in version control system support in either of these two IDE:s. I’ve gone through Subversive, Subclipse, SVNkit, Git, and Mercurial — and none of them, in combination with NetBeans or Eclipse, can handle this.

So I’m asking myself (and you) .. what’s f-ing problem?!? Why can’t NetBeans and Eclipse just treat the remote project as any other project? Why can’t I simply be allowed to create a remote project, and then specify the appropriate parameters for version control and be allowed to utilize the power of version control from within the IDE?

Using something like SSHfs to “trick” NetBeans and Eclipse into thinking it’s a local project won’t work either due to the really poor performance of SSHfs (Ubuntu 10.10). Obviously, the solution needs to handle not just me working on the same project from many locations, it also has to support other developers working on the same project, from many locations. All Eclipse-based editors (EclipsePDT, Zend Studio, Aptana, etc) suffer from the same problem since they use the same plugins.

Searching the web for this issue, I’ve come across many requests for this, but not a single solution; which, given the nature of Internet, is a pretty rare thing. I could never in my wildest imagination (and it’s pretty far out) had thought that I’d be having a beef with something as common as a remote server or remote file system in the year 2010 🙁

Leave a Comment

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.