Almost a year ago I wrote about my initial thoughts on switching from Subclipse to Subversive, and it continues to be one of my most-googled posts -- not to mention that people encouraged me at the time to follow up later. I think it's about time.
Where are they now?
The first question is, of course, do I still use Subversive instead of Subclipse? The answer is yes... when I have to use Subversion at all.
To be honest, I've moved as much as is possible to Git -- even more than was true when I wrote my last entry. I mentioned at the time that I preferred using Git for my personal projects, for which I didn't have to worry about collaborators resisting the change, because there are no collaborators when working alone. But I spend more time working as part of a team (at work) than I do working on my personal projects, and 90.6976% of my work projects use Subversion. For a while I continued to use Subversive, and it got the job done, without the problems I experienced in Subclipse. Subversive is available through the official Eclipse Helios update site, which is probably an indicator of general consensus on the better option.
Then I started playing with git-svn, hoping I could make it work well for my needs. A few weeks later, a colleague on another team posted a blog entry about how he was using git-svn for his work projects. I guess that was what pushed me over the edge, because before his entry I was only using git-svn for 1 project, and after, I started using it everywhere possible.
Git-SVN
Git-SVN is a bridge baked into git -- not a separate tool you need to install -- that allows you to use Git as your SVN client. You can create a local copy (a git clone) of a subversion repository, use it just as you would any other git repository, and then push your changes back into the subversion repository when you're ready. The process is fast and painless enough to read from and write to your subversion repository all day long. In case it doesn't go without saying, this is tremendous.
There are lots of things to consider when working collaboratively using git-svn. The workflow choices are numerous and all outside the scope of this entry. But the important takeaway is that if you're a git-head, and I am, then most of the time you can use git-svn instead of Subversion.
When can't you use git-svn? The situation where I still find myself using Subversion, and thus Subversive, is when I'm working on a shared project on a remote development server and setting the project up to run locally would take longer than making the code changes. Not only would the setup be more onerous, but after pushing my changes back into the SVN repo, I would have to go run an svn up on the shared development server -- one more thing to forget to do. Other than those types of projects, I've been svn-free for several months now.
Take the plunge
Distributed version control is here to stay. DVCS isn't going to kill SVN, just as SVN didn't kill CVS, but if you want to work on distributed agile teams (for example, most modern open source projects), DVCS is the clear choice. It may be another flavour: Mercurial, Bazaar, etc; but the concepts should pretty easily transfer between them. In the long run, you'll be better off for having learned something new.
in
Git |
Subversion |
3 Responses
Posted 2011-02-25 04:30
I seem to struggle with this particular dialog every time I use it, which is sort of a self-fulfilling prophecy. The merge dialog is confusing, so I create less branches, and since I create less branches I see it less, and the less I see it, the less I remember about it, which makes it more confusing.
There is a reason I've switched to Git (wherever possible), after all.
Since I just figured out how to do the type of merge I wanted (again), I figured I would document it here for myself as much as anyone else who might be experiencing the same frustrations.
The process goes like this:
- Switch to the location that you want the result of the merge to end up in. This could be a branch, if you are merging from branch to branch, as I was in this case.
- Right click the project folder (or other target of the merge) and choose Team > Merge.
- Select the URL option from the tab bar at the top
- Browse for the URL of the branch that contains the changes you want to merge (into your current location)
- "Start from copy" may have worked, but I wanted to see what was going to happen so I chose specific revisions. The browse dialog showed only the revisions specific to the branch I was merging from, including the copy action that created the branch. I selected everything except the copy.
- Preview, which should show exactly what you are expecting to happen. In my case, a couple of adds, and a majority modifications. No conflicts occurred because I was careful not to do anything in the target branch while working on my sub-branch.
If satisfied with the preview, run it for real by choosing OK. And of course, if something goes wrong, you can always revert and try again.
in
Subversion |
No Responses Yet
Posted 2010-12-15 12:28
For my personal projects, I have switched entirely over to Git for version control. However, at work I still have to use Subversion so that everyone on my team can share. That is not to say that Git isn't perfectly capable of working for our team, but that the team isn't ready to make the switch.
While I am extremely curious about the prospect of using Git as my Subversion client -- something that I understand is not difficult to do -- I haven't yet worked up the nerve to try it on something as important as a work project. I can't afford for something to go wrong. So for the time being, I'm still using native SVN clients.
Recently I decided that I would give the Subversive client a try. When I first started with SVN I used Tortoise, and when I started developing with Eclipse and CFEclipse, there seemed to be (after very little research) a consensus that Subclipse was the better client; so it's what I've used for the last few years.
Myself and at least one other coworker have been using Subclipse and having some problems that we believe may be unique to Subclipse -- or at least to using Subclipse in our environment. We often have projects checked out onto a shared drive and have sometimes run into a situation where a commit can't be made from the root, or issues when selecting a few individual files in disparate directories. Suffice it to say, frustration is setting in and while the command-line works, it would be nice if IDE integration worked.
So that's why I'm trying something new. Not only is Subversive now an official part of the Eclipse project (a nice endorsement), but I've heard lots of praise for it recently. I've always wondered if I had made the right choice going with Subclipse, so now I'm aiming to find out.
Speed
My very first impression was how fast it seems to be. I haven't done direct side-by-side comparisons, but from a subjective standpoint it feels like browsing a large repository -- the Mango Blog repository, for example -- is extremely fast. Even a checkout seemed faster. And you can't complain about too much speed.
Does it work?
Of course, most importantly, is the reason that I switched: Does it work in cases where Subclipse seemed to fail us before. The answer is short and sweet: Yes! So far, I haven't run into any similar complaints about Subversive.
Shortcuts
I never knew how much I needed keyboard shortcuts for version control.
Update? Ctrl+Alt+U
Commit? Ctrl+Alt+C
Compare with latest from repository? Ctrl+Alt+L
And the list goes on. I could never switch to an Eclipse-based SVN client that didn't have these or similar keyboard shortcuts available and not experience some serious frustration.
Any complaints?
Actually, yes. I was quite surprised to find that after installing the client through the Eclipse update site, it still wasn't fully installed. It seemed like there was a framework in place for the functionality, but the first time I tried to anything with a repository, I was prompted to install a connector -- a step that (to the developer's credit) Subclipse completes during the original installation.
Now, this may not be that big of a deal, and I suppose it really isn't, but I am trying hard to use UAC in Windows 7. I have my reasons, but suffice it to say that I want my relationship with UAC in Windows 7 to work out. In order to install the plugin in the first place, I had to run CFBuilder as an administrator. Fine, did that. After the install, I was prompted to restart. Ok, that's not desirable, but fairly reasonable. Once I try to connect to a repository, I'm prompted to install a connector -- but oh wait, you can't just install it, you have to exit CFBuilder, run as an administrator, and install the connector. And then restart again, of course.
It's not the end of the world, but it was annoying enough that I thought I should mention it. And it's not CFBuilder's fault at all, this is a combination of seemingly-odd choices by the plugin developers and Windows UAC pains.
Do I recommend it?
Absolutely. Even if for the keyboard shortcuts alone. That plus added speed is a no-brainer for me. Where I can't use Git, I'll be using Subversive.
in
CFBuilder |
Subversion |
11 Responses
Posted 2010-05-13 11:05
I'm giving a presentation at the end of the month on Subversion for my office. It's going to be recorded and I'll be sure to post the video here for anyone interested in watching.
Here's where I need your help: What are some of the craziest, dumbest, most ridiculous things you've ever seen done in Subversion (or some other version control system, as long as the scenario would still apply)?
Anything is fair game. Awful commit comments? Terrible branching or merging practices? I want to hear about it all, and I welcome your comments!
in
Best Practices |
Subversion |
1 Response
Posted 2009-05-11 04:25
