I have not posted to this blog in quite a while. I have been thinking about using it to blog some personal thoughts (like on the Red Sox) but I know it is syndicated in a few places for its Subversion/Subclipse content so I haven't. Instead, I have been doing all of my Subversion blogging over on the Submerged blog at openCollabNet.
It has been a busy summer. I have been more involved in the Subversion community than at any time in the past. Earlier in the summer I was made a full committer which was a proud moment and I have been doing a lot of work to help drive us to the final 1.5 release. Beyond all of that, what I have really been working on the most, however, is the development of a new GUI merge client for Subversion to coincide with the Subversion 1.5 release. Yesterday, we officially announced the client and released an early version. You can read the blog post here, or skip right to the details here.
The CollabNet Merge Client is built on top of Eclipse and Subclipse and has the simple goal of making merge easier. I think it does that and a lot more. It has really turned out great. There are details on the web site, so I will not reiterate them here.
As part of developing this client, we have also made a lot of really nice enhancements to Subclipse. We have focused on taking advantage of all of the great new features that are coming in Subversion 1.5 and also on general usability. I think the final result is going to be great.
The Subversion community is working hard to get the Subversion 1.5 release process started by mid-October so that it can be GA in December. The GA of Subclipse 1.4 and the CollabNet Merge Client will be at the same time.
If you use Subversion and Eclipse, even if you do not use Eclipse, I would encourage you to check this out and give it a try. It requires using the latest build of Subversion 1.5 on the client, but that is not as risky as it sounds, and we will be refreshing the client with new builds as needed. We are also providing Linux JavaHL binaries to make it easier for Linux users to try. Currently only OSX users are shut out, which is ironic because I do all my development on OSX. We could probably make a 1.5-trunk installer for OSX but it would take some work to make it co-exist with the existing 1.4.4 client for OSX. I know Jeremy has been busy so I have not asked him to do the work required. At worst this problem will go away when 1.5 is GA, but hopefully we will have something available before then.
CollabNet Desktop - Eclipse Edition
There was one other aspect to this, yet another thing I have not blogged about. That is the CollabNet Desktop - Eclipse Edition. This is a unified set of tools to access all CollabNet products from Eclipse. We include Subclipse for accessing CollabNet Subversion repositories. There is also a small UI layer on top of this to integrate into the CollabNet perspective and sites view.
It also includes connectors for Mylyn to integrate the issue trackers available in CollabNet Enterprise Edition (CEE) into Eclipse. There are a lot of popular open source sites that use CEE such as tigris.org, java.net, openoffice.org, netbeans.org, dev2dev.bea.com etc. Now the issue trackers for all of these sites are available in Eclipse and Mylyn.
We are also currently working on a Mylyn connector for the issue tracker in SourceForge Enterprise Edition, which is now a CollabNet product. Note: This is not the same product that runs on sourceforge.net.
Last but not least, we also provide integration and access to CollabNet CUBiT. This is a really cool product and the integration came out great. CUBiT allows you to virtualize your build and test environments. From Eclipse, I can provision a server in our CUBiT environment, this includes picking the operating system to run and possibly a set of other components I want to install such as MySQL, Apache etc. These servers are accessible via SSH, and the CollabNet Desktop client makes it simple to access the servers and setup port forwarding to access services running on the servers etc. We integrated the SSH Terminal from the Eclipse DSDP/TM project to provide terminal access. We also support launching external clients but none are required.
I use CUBiT to dynamically provision servers to test Subversion releases (which I have to test on Windows, Linux and Solaris), but most people are using it to build, run and debug server-based web applications. Anyway, the CollabNet Desktop was just another of the many things I have been working on this summer and it went GA a few weeks ago.
It has been a busy summer.
9 comments:
Ouch, Mark! This new merge tool is really awesome, but why haven't you used Synchronize view to show the results (lice CVS tools does) and created a custom view that waste some more screen real estate...
I tried to address it in the overview document (pretty much just for you since I knew you would ask).
We wanted to represent skipped items, and eventually try to do something for move/rename. I am not saying that we could not have done these things with the Synchronize view. I just was not sure if we could and it just increases the work involved significantly.
Personally, I find it awkward to use the same view for two sort of different things. At the same time, I clearly see the value in the view which you can see by how hard we have tried to recreate it.
Now that the bulk of the work is done, there is always the possibility to revisit this sometime in the future.
Thanks for the explanation, Mark. I understand that it is usually harder to reuse existing UI, but from the user experience point of view it seem won't be necessary to use both views at the same time, so why not reuse the existing one. So, I hope you'll have chance to somehow address this in the future.
Hi,
Is there a way to get the Mylyn plugin for CollabNet Enterprise edition (like, for java.net) for free? Or, is it only available to commercial users?
The CollabNet Desktop is free software. You install it via an Eclipse update site (or zipped download of update site). The instructions are on the site:
http://eclipse.open.collab.net/
Sorry if that was not clear.
It's unfortunate that you introduced a separate UI. This will make it even more difficult for Eclipse CVS users to switch to SVN. I'm pretty sure that the Synchronize View could have been enhanced for really *all* the needs you have.
Another usability issue I saw while reading through the docs is this one: http://merge-tracking.open.collab.net/images/handle-conflict.png. There is no value in this dialog because I don't see the actual diff so how would I make a decision?
Can we discuss on the forum? It is a little easier than blog comments.
http://merge-tracking.open.collab.net/servlets/ForumMessageList?forumID=57
Maybe I just suffer from having not used CVS since Eclipse 1.0 but I do not see why using the Synch view for a merge, and then taking the Synchronize option to do a different kind of synch is a better UI. I also do not see how this is even worth debating at this point or how this is going to make it "even more difficult" to switch. As compared to what? You think this client is going to make it more difficult to switch as compared to the options available today?
As for the dialog, how can you say it is worthless? The merge has encountered a conflict and it is asking if you want to try to resolve it. What are the diffs it would show here? They do not exist. We have three files, we are asking if you want to see a 3-way diff and resolve the conflicts. I don't get what the usability issue is. Regardless, there are no diffs to show and there is an option to just let the merge run and then work with all the results on-demand from the view.
Just to followup and be clear about something, I am not against the idea of using the Synchronize view. We actually bounced this around quite a bit during the design phase. In agile terms, the most business value was in the actual merge results and the approach we took delivered that the quickest. Using the synchronize view was a high points/low value story.
In terms of getting us to revisit this sooner rather than later please give concrete explanations of the usability reasons. Don't assume I just see them. So far the comments have seemed like there was more of an emotional attachment involved. I am sure there are good usability reasons why one approach would be better than the other, just take the time to articulate them.
And again, the best place to do this is in the merge forum on openCollabNet.
Hi, I was just curious what the time frame for Mylyn adapter for SFEE is. I'm looking forward to see it in action!
Matthias
Post a Comment