Subclipse, Subversive, or something else?
There's a bit of debate around the topic, can we come to some conclusion here?
EDIT:
It's been a couple months now, and I ended up deciding the plugin slowed Eclipse down too much, and was a hassle to use every time I changed a file from outside Eclipse.
I ditched the plugin all together and just went with TortiseSVN.
This depends. Subclipse has superior support for checking out projects as maven projects - this is the sole reason we use Subclipse. Other than that, I have noticed subclipse bugs with syncing with SVN.
Subversive is much better at detecting new files to add to version control, and is also far superior with merging code from a branch, or even syncing with SVN (fewer bugs, etc.). So really, you should ask yourself what value you want. If you're not using maven, I would definitely go for Subversive.
I've recently switched from subclipse to subversive. After upgrading our repository from v1.4.x to 1.5, we started having lots of issues with subclipse.
After doing a synch, you'd see updates that you had just accepted, and you wouldn't be able to take other updates without doing "hacks"
So far subversive is pretty nice. it even seems a little faster for lots of small files than subclipse was.
Personally i use subversive. It has better usability features, mainly intuitive keyboard shortcuts etc.
I have never had a problem using either though. It really is just a combination of personal preference and usage though, if you're using advanced complex features it might matter which one you choose, but if your just checking in, checking out and synchronizing they will both meet your needs.
I'm casting my vote for Subclipse. I've had better luck with it than Subversive personally.
subclipse is fully packed with features, I have never had an issue with it.
Related
I would like to make a new plugin for a programming language because there is not any IDE the time I asked this question. I think IDE developing is far more easier if I try to use one of the available platform like Netbeans or Eclipse or ...
As I checked, Eclipse plugin (if that plugin is not updated) won't be able to start up after 1 or 2 years. I mean, Eclipse develops a way that old plugins has to follow in order to hold the compatibility.
I can't answer your original question as I have not developed for Netbeans.
As the backwards compatibility, if the version dependencies are set right, and only the API from other plug-ins are used, the old plug-in should work (there are some exceptions, but in that case upgrading the plug-in does not take too much effort, as there is documentation about what has changed).
The main drawback in Eclipse development is that documentation is sometimes scarce, but for common tasks there is some available.
Sorry, I also can answer only 1/2 of your question.
I have developed (small) eclipse plugins and an eclipse RCP. Both were a breeze. I agree with #Zoltan's comment, get your dependencies right & don't use some back-door unsupported feature in aplugin you don't control & your problems should be minimal. Even if you did run into a dependency problem, the configuration is straightforward enough that you could make an updated release of your plugin very quickly.
The Eclipse Visual Editor project seems to be dead, no commits, no updates. Any one know what is happening?
Update 2: The project has been archived (i.e. dead) since June 2011 again.
Update: The project has been revived and is now under active development again.
Its pretty much dead due to a lack of developer support. Here are some recent posts from their mailing list talking about a lack of movement on the project.
What's happening? It's called NetBeans, and it's already happened.
I'm going to get voted down for this but they know it's true. I love eclipse and have used it religiously since I started Java. I'm not saying I like Netbeans, it's just all I hear whenever the concept of a Java visual editor is brought up.
The Jigloo plug-in for Eclipse is a pretty great alternative to the Visual Editor. Though still not quite as nice as the Netbeans GUI editor it is fairly robust and fully featured, especially compared to what was available in the Visual Editor plug-in. Definitely should give it a shot.
Actually NetBeans has gotten MUCH MUCH better. I've used Eclipse, Netbeans and IntelliJ for a few years each, and NetBeans is at least as good (performance, usability & features) as the others now.
It's also improving more quickly than the others are.
They have people working full time on alternate language support, so you'll find they have the best Ruby support in the industry, and I believe Python is about to become that good as well.
Of course, Eclipse still has that crazy-cool todo list that remembers which files you worked on for each bug and can take you back to the set of files/edits for any bug you've worked on, that's really amazing to use and I don't think it's available on either of the other platforms.
--- Revision from years in the future ---
I have used Netbeans more and really have to give the award to Eclipse. The difference has been in vertical programming environments--most will target Eclipse and ignore netbeans. You rarely need these, but when you need them there is often no way around them. If Netbeans does have an equivalent, it's often buggy to the point of not being usable, generally the biggest issue is emulator support.
You won't run into these unless you are working in a specific industry--Android development is one, the primary drive was to support Eclipse, NB seems to trail. Another I've worked on is in the TV/Cable industry.
For raw java development, however, I'd still give Netbeans a little edge because it's the environment that was targeted and supported by sun.
Visual Editor is doing a new release, 1.4, on September 16. Installation instructions for the RC are here:
http://wiki.eclipse.org/VE/Update
FWIW, the project did stall for a while. But there is a new, and relatively diverse group of folks working on it again. Most of the recent work is concerned with making the new release compatible with Eclipse Galileo.
It's officially dead as of May 2011. It's archived here, but slow to download and tricky to install. Instead, there's a new editor, WindowBuilder Pro.
Currentlty Google have Open Sourced the Windows Builder Pro. It seems nice
yeap,
http://www.eclipsezone.com/eclipse/forums/t91368.html
Yes, sadly, it is dead. Looking at the aforementioned email threads regarding it's revival I get the feeling that even if it does get picked up it will quickly collapse under the weight of some new requirements ("make it universal, edit everything from SWT to HTML").
WindowBuilder can be a good alternative. I had several problems with VE and I end up with WindowBuilder who worked for me perfectly.
http://www.eclipse.org/windowbuilder/
I've personally always used some type of external application for my SCM work; these days, that means tortoiseSVN on windows and versions.app on the mac. However, I keep running up against developers (namely eclipse users) who argue that SCM is better done within the IDE itself. I've yet to hear any really compelling arguments in favor of this workflow, and I personally like a degree of "separation" between the IDE and SCM operations. This has been burned into me from using unstable SVN plugins in Visual Studio, and the sub-standard SVN support in Xcode in years past when working offline.
Which way promotes the better workflow in your opinion?
For basic operations - Check in Check out I like it right in the IDE, for anything much more advanced, (branch/merge) I prefer to use the external tools.
External tools seems to give better control/options in those circumstances. Your choices seem to be limited or non-existent when working directly in the IDE.
I definitely prefer outside. That being said, my primary IDE is Visual Studio, and I haven't used eclipse or intellij (although I have used cvs-mode in emacs...), so your mileage may vary...
Making changes and committing changes are separate tasks - having them both be easily available in the IDE means you don't clearly delineate between completing a set of changes and committing them. Quite often it's a case of type type type, compile, test, test, commit...'oh, wait - I forgot to foo the bar as well. Context switching from IDE mode to SCM mode tends to trigger the 'oh, wait' before the commit.
Keeping related files for commits together - it's all too easy to commit source changes, then remember the related SQL scripts and commit those separately and then add the new image files as you forgot those because they're new to the repository and so on.
Similar to the above, it tends to be a lot easier to commit things at the wrong level/directory in the repository when in the IDE. (e.g. I should have committed at solution level, not project level)
It tends to be easier to get a complete diff of your workspace against the repository outside the IDE, which is often worthwhile.
It also probably makes your IDE that extra bit faster
I also agree with a previous poster - all non-trivial SCM tasks tend to be easier outside development IDE integration.
To be honest, as long as you're avoiding messy commit situations described above, do whatever you find most comfortable. In terms of workflow - the separation has to be 'cleaner', whether this cleanliness outweighs the convenience is going to be in the eye of the beholder - we're largely reacting to our personal experience (I suspect mine is similar to yours).
Whatever you do, use anything but SourceSafe... I have to at the moment for legacy code - I find it abhorrent that files are made read only and that the SCM integration physically alters the contents of files...
One advantage to having the integration is in refactoring. If I renamed a class in Java (and thus the file name), your SCM integration would automatically handle the rename operation (a delete and then an add in svn, for example).
It also is very handy to be able to say, "show me the history of this file" or whatever while you are working on it, without having to drop to Windows Explorer or the command line or whatever.
But I like being able to have both available, honestly.
I almost always use external tools. The only exception is when I need to rename a source file. It is just so much easier for the IDE to update its project references at the same time.
It very much depends on the IDE/SCM combination. I'm currently using IntelliJ with SVN, and find that IntelliJ's SVN plugin is generally much more pleasant to use than Tortoise. Not that I have any particular complaints about Tortoise -- IntelliJ is just better.
Building should be possible without IDE so SCM should be possible without IDE.
On other hand, having IDE support the SCM can be convenient. It is nice to be able for example check the file history easily and maybe revert it.
I like internal SCM for.
Renaming files, rather than having to do the rename in the IDE and the SCM tools
Adding files to a project - see above
I find with an internal SCM it is less common for developers to forget to add new files to the SCM system.
For any complex operation, e.g. merge, branch, etc I tend to use an external SCM GUI or command line.
I'm looking for a tool like Atlassian's FishEye. The alternatives I've found so far (like StatCVS, ViewCVS or Bonsai) are either lacking in features or are quite a pain to install and maintain. So before staying with one of these tools, I'd like to be sure I did not miss any other good, easy to install, open-source (prefereably java) version control-viewer which supports cvs as scm.
Another SVN tool which has repository browsing capabilities is Trac. This is nice because as well as a browser for the repository it also has a timeline showing commits. It also does bug tracking.
Warehouse is pretty cool
ViewVC is a good open source, web based, repository viewer similar to FishEye. I know you've looked at it, and you're right, it was a hassle to set up, but once setup, it's run without any intervention for almost three years for us.
There is also CVS Monitor, though it hasn't got the nearly the number of features as FishEye.
We use ViewCVS for repository browsing.
If you were using SVN I'd highly recommend Tortoise SVN.
So I want to get a project on a distributed version control system, such as mercurial, git, or bazaar. The catch is that I need the Windows support to be good, i.e. no instructions that start off with "install cygwin...". Now I've heard that git's Windows support is decent these days, but don't have any first hand experience. Also, it sounds like the bazaar team has an explicit goal of making it as multiplatform as possible.
Can I get any recommendations?
I use msys-git on windows every single day. Works fast and flawlessly.
Although the newer build has some problems with git-svn, this build (Git-1.5.5-preview20080413.exe) has a working git-svn.
There's a nice comparison between git, hg and bzr in this InfoQ article. They all have their strengths and weaknesses. You'll have to think about your project and your workflows and choose the best fit. The good news is that they're all fairly good.
At last I checked, the only thing you need for Mercurial is Python and to grab a binary package. If you find yourself with more time and want to fiddle / build it yourself, look here.
The only real drawback with HG is its idea of branching .. but for some people that's a major plus.
I like it because its intuitive, easy to install and works on anything that Python does. I don't think that all of the available plugins will work for you, but most should.
I've had the best luck with Bazaar, followed by Mercurial. Never could get Git to work correctly. A quick search shows that Git still requires clunky emulation layers like Cygwin/MSYS, and I can't find any integration tools like TortoiseBzr for Git.
With Mercurial in Windows, I had several minor issues (insensitive paths, symlinks, ). They were usually fixed eventually, but I felt that the same quality of testing was not applied to running on Windows as for the other platforms. Bazaar also had better documentation for integrating with native applications like Visual C.
EDIT: Perhaps add a "dvcs", "distrubutedversioncontrol", "distrubuted"
I've used Mercurial on Windows with no problems. You can use TortoiseHG or just use the command line. Mercurial does require Python, but that is easy to install in Windows as well.
Mercurial Binary Packages
I agree with basszero. I'm using mercurial under windows and it's as easy and reliable as it can get. My development team is spread over Europe (well Dublin and Vienna :-).
We use VPN to commit or sometime the built in webserver (hgserve). Both work fine with no problems out of the box.
Also diff3 open source tool works perfect with mercurial and TortoiseHG out of the box.
If you are concerned about an easy to use interface:
The bazaar folk now include TortoiseBzr in their windows binary package. That's got to be a pretty strong indicator that they think it is up to snuff. I don't know what the maturity/stability of TortoiseHg is, but there certainly isn't a decent GUI interface for git yet, and the MSYS git build still needs some work IMO.
If your team are comfortable with or prefer the command line, then either bazaar or mercurial would probably work well for you, and are both probably about the same in terms of learning curve. Git's learning curve is much higher. It is like the swiss-army knife that is almost wider than it is long, with all the little gadgets and do-dads in it and hanging off it, with the springs so tight that you occasionally slice a finger open trying to prise a blade out.
In my experience using GIT on windows is a major pain. But I have been using Fossil SCM for some time now, and I think it actually fits your needs exactly.
It also has a built in Ticket system and a Wiki. And the whole program is contained in 1 file and it works right out of the box.
I totally recommend it.
Here is a link to the site http://www.fossil-scm.org/
Remember, this site is self hosting, what that means is you are looking at the web interface to fossil it self, when you look at tickets and the wiki and documentation, you actually are using fossil.
But if your project has millions of lines of code and is a few gigabytes in size, you have to use GIT, there is no way around that problem.
Enjoy.