I was talking with a guy the other day about version control using Subversion, specifically with the Subclipse plugin. He mentioned that he had not found a way to get Subclipse to do an atomic commit across projects.
I'm new to Subclipse but am interested in learning more and this looked like an interesting topic. I did a bit of searching on the 'net and some experimentation. Bottom line: Subclipse will do an atomic commit across projects, but only if configured correctly and if your projects are organized correctly within Eclipse.
The configuration issue is easy. AFAICT, you have two choices for the underlying interface to Subversion when you use the Subclipse plugin: SVNKit and JavaHL. SVNKit has apparently had support for doing an atomic commit across projects for some time now. In JavaHL, however, the support was not added until Subclipse version 1.3.1. Further, there is an option that must be set when using JavaHL: Window > Preferences > Team > SVN > JavaHL: Commit across multiple projects atomically.
Project organization is a bit more complicated. I have a local test repository that looks like this:
$ svn ls file:///c:/Demo/vcs/repositories/svn-local
/Hello
/Primes
I did two experiments, using Subversion v1.5.3, Eclipse v3.4.1, Subclipse v1.4.6, JavaHL v1.5.4 (r33841), and SVNKit v1.2.0.4949.
In the first experiment, I used the svn command line tools to checkout each project to different working copy directories: C:/Demo/Projects/Prime/Subversion/Primes and C:/Demo/Projects/Hello/Subversion/Hello. Then from within Eclipse I created two projects, each time using File > New > Java Project. In the New Java Project wizard I chose the Create project from existing source option so that I could select the correct working copy directory. Note that this means the Eclipse projects are not put into my Eclipse workspace directory.
I modified one file in each project and then with both modified files selected I right-clicked one of them and chose Team > Commit. When configured with SVNKit, Subclipse produced a Null Pointer Exception. Bummer. With JavaHL there was no error, but instead of a single atomic commit I got two commits:
commit -m "with JavaHL" C:/Demo/Projects/Prime/Subversion/Primes/Prime.java
Sending Demo/Projects/Prime/Subversion/Primes/Prime.java
Transmitting file data ...
Committed revision 9.
commit -m "with JavaHL" C:/Demo/Projects/Hello/Subversion/Hello/Hello.java
Sending Demo/Projects/Hello/Subversion/Hello/Hello.java
Transmitting file data ...
Committed revision 10.
In the second experiment I had Subclipse create the two projects in my Eclipse workspace by using File > Import > SVN > Checkout Projects from SVN. I repeated the process of modifying one file in each project and then attempted a commit. Both SVNKit and JavaHL worked correctly and did a single atomic commit:
commit -m "from the same workspace" C:/Users/greggs/workspace2/Hello/Hello.java C:/Users/greggs/workspace2/Primes/Prime.java
Sending Users/greggs/workspace2/Hello/Hello.java
Sending Users/greggs/workspace2/Primes/Prime.java
Transmitting file data ...
Committed revision 11.
Why the difference between the two experiments? The answer comes from the project lead for Subclipse, Mark Phippard in a thread on the Subclipse Users email list: "commits are still grouped by the parent folder of the projects in
your workspace" (emphasis added).
In my first experiment, from the Eclipse IDE's point of view those two projects did not have a common parent folder. In my second experiment, the Eclipse IDE (and by extension, the Subclipse plugin) did see a common parent folder for the two projects and was therefore able to do a single commit.
Read the full thread for all the details, but the bottom line is that when projects are checked out of Subversion using Subclipse into a single workspace, Subclipse will do an atomic commit across projects.