Tim forgets again to reply-all :-) ------------ Forwarded Message ------------ Date: Tuesday, September 27, 2005 11:38 PM -0700 From: Tim Shadel <[EMAIL PROTECTED]> To: Philip Johnson <[EMAIL PROTECTED]> Subject: Re: [HACKYSTAT-DEV-L] eclipse, subversion, subclipse...
Hey all, Here's my response in typical firehose fashion. :-) Summary: make the switch, Subversion is worth is and Subclipse is stable.
(a) Has anyone had experience with the subclipse plugin? If so, how much, and on what platforms? Is it stable? Easy to use? etc?
I've used subclipse for over a year now. I've posted negatively about it a few times in the past (http://timshadel.com/blog/tag/subclipse), but that was over a year ago. Subclipse has come to be stable recently. We used to have problems with it even as much as 6 months ago, but things have really quieted down since. I've only used it seriously on Windows. I think I may have it installed on my Mac, but I'm mainly doing Ruby stuff there. As for ease of use -- definitely easy. That's the only interface to Subversion that most of our 30-ish developers use. Some use TortoiseSVN as well, and a few use the command-line. It integrates well with Eclipse.
(b) Has anyone used the refactoring integration of subclipse? If so, did it work? was it easy? etc.
This is the only reason I really use subclipse (I prefer the command line myself -- total geek I guess). But I wouldn't attempt any serious refactoring without it. I left CVS back over two years ago simply for the directory renaming that Subversion provides. I used to do those things by hand, and SVN let me keep my version control reasonably clean. Now I only use Eclipse refactorings to do that stuff since Subclipse manages all the heavy lifting. I still keep it fairly light (I'll move a bunch of classes and then commit, then I'll rerrange directories and commit, etc.). This may be out of habit from the early Subclipse days of instability, or it may simply be that it keeps things clear in my head when I don't try to do a whole lot at once. Something I haven't really used with Subclipse is the Synchronize with Repository perspective. I've tried it a few times, and it's really awesome with CVS, but SVN provides "svn st -u" that really meets my needs pretty well already. The early versions of Subclipse didn't support the Synchronize, but that support has been in there for 6 months +. I'm assuming it's pretty reliable...I just haven't used it enough to say definitively.
(c) are there other plugins out there we should be considering?
Nope. You'll see a few references to other plugins, but they're all vaporware. This is the only mature one.
Anything else we should know before jumping off the cliff?
Jump. :-) Subversion is seriously much more productive and helpful than CVS. It does take some getting used to though. A few nuggets of advice: 1) Try to avoid "thinking in CVS", and adopt Subversion-style repository naming conventions and layouts from the very beginning. Read through the the SVN book's (http://svnbook.com) Appendix A, Subversion for CVS Users. That should get you started. 2) Read a good book on Subversion. I'd recommend two: Pragmatic Version Control Using Subversion (http://www.pragmaticprogrammer.com/titles/svn/index.html), and the O'Reilly Version Control with Subversion (http://svnbook.com). The latter one is published for free on the internet, and it's a great go-to reference. I think Subclipse installs it as an Eclipse help file as well. 3) Learn very early on *why* Subversion revision numbers are different from CVS revision numbers. This is a big key to the "Subversion philiosophy", and it'll change the way you work with your version control. Consequently lots of things will seem to come easier and you'll find uses for stuff you'd never have thought of otherwise. 4) Take some time to follow how Subversion does branching and tagging. CVS made branching worse than 10 years' dentist appointments back to back. It's now reasonable in Subversion, and with a little forethought you can use it judiciously to support your process. An _excellent_ and **simple** guide to simple version control strategies (regardless of tool) is Software Configuration Management Patterns (http://amazon.com/o/ASIN/0201741172/). the book is _very_ plain and the best read on version control I've ever seen. Even Brad Appleton's site (he's a minor co-author, I think, but big expert on versioning stuff) is incredibly impenetrable compared to the book. He sets up great guidelines for when and why to use branching. We've tried to follow his branching advice, and have done so fairly successfully, I think. We've found that Subversion branches work well in tandem with Eclipse Workspaces. For example, if your working copy has /trunk/ for all your projects (hacky*), and then your working copy has /branches/hacky-6.7.x (again, with hacky* under that), then you can easily setup one Eclipse workspace that loads all the projects from your main development area and switch to another workspace (File | Switch workspace...) to work on the release that's stabilizing while new development continues. Remember here that your Eclipse workspace directories can live anywhere on your drive, and you can load your project directories from another place entirely. 5) Consider several options for bringing your source code into Subversion. They have a script that will recreate your CVS repository in Subversion. I really haven't used it very much, but all indications I've seen are that it's been very reliable for quite some time (I haven't seen any specifics on how it handles branches or tags -- but regardless of how it brings those over, don't forget point #1 above). Mostly we decided that historical source code would be archived. If we needed to get to it we would wllingly use CVS. We brought the code over at a reasonably clean point, and just started from there. So far we haven't had any need to open up the old CVS repositories. In the end, though, it's your data and you've got to decide what's important to how you want to work. 6) Make a local Subversion repository, and play with it for an hour using the file:/// protocol. Try to do nearly everything in the examples out of one of the books you see. It'll help you get the feel for it pretty quickly, and you'll see what's similar to CVS and what's different. Enjoy, Tim ---------- End Forwarded Message ----------
