Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have heard from my peers on more than one occasion that it is "advised" not to do version controlling of your code from within the IDE where you write it. I have seen them developing on Eclipse, IntelliJ IDEA, etc. but doing version control (in my current scenario - Git) from command-line or standalone clients as opposed to using the corresponding plugins readily available for the IDE.
Though I have used version control plugins in Eclipse and never found any issues, I would like to know what is the general norm and why?
I don't think that there's a general norm. The answer to the question is highly subjective.
I personally don't use any IDE integration (not even a GUI tool, except the builtin ones git gui and gitk) because my experience told me that these tools behave different than the command line version and/or don't provide the full functionality available on the command line:
Does NetBeans ignore my Git pre-commit hook?
Can you interact with the index/staging area with TortoiseGit?
Does TortoiseGit actually make Git a lot easier to use like TortoiseSVN?
Another thing is that your knowledge about your versioning tools is bound to your IDE. Maybe you want to set up some version management for other things than the sources you edit with Eclipse (your dotfiles, for example).
Or one day you switch your IDE, drop Eclipse and start using Visual Studio. Then you don't have to learn only Visual Studio but in addition you need to learn the Git integration in VS too.
I think compared with what I've written above, there are no serious advantages that would legitimate the usage of version control tools from inside the IDE.
So, IMO, it's a bad practice to do version control from inside the IDE and it should always be done from the outside.
You should always try to use the right tool for the job, and that is a personal question so there is no "norm" or "good practice".
In my case I prefer to use a ...
GUI, like Sourcetree, for viewing logs, diffs, staging/discarding lots of files, staging/discarding hunks, etc.
CLI for modifying remotes, squashing commits, pushing, cloning, etc.
Also, if you plan to break out of the box a little bit, it wouldn't hurt to know a little bit about the Git internals.
Those plugins and add-ones tend to sometime do things that otherwise you wouldn't do if you were using the native (CLI?) client.
For example, if you were working with an Eclipse + ClearCase plugin, any change in a file, even adding a new line, will initiate a check-out operation (depending on the configuration).
Specifically for Git, you should be aware of its internals to properly work with it. Using the IDE hides those things from you. In normal trivial operations, it will work. But, when you are facing a source control issue (ugly merge, cherry-picking, rebase conflicts) you will have to go to the CLI to resolve, but then you have no idea what were the actual commands that the IDE ran that got you to this situation in the first place (plus you have no experience with the CLI at that point).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I would start a J2SE projects for abuntu OS.
I try both Netbeans GUI builder and Eclipse windowbuilder.
Both of them are good, drag&drop, double-click to create event-handler like VisualStudio.
However i have do a research on Netbeans, someone said:
The second major flaw of Matisse is that it just isn't good enough,
you place the components on the grid, Matisse then creates an XML with
the component's attributes, then generates the java code for the
components on the grid. Seems cool, but then you decide you want to
add a button somewhere in the form or resize a component - this
procedure can cause all of the gui to get mixed up throwing the
adjacent components to different places - fixing it can be a pain in
the neck. Even if you managed to place all of the components where
they should be but manually changed some of the generated netbeans
code - you are in a BIG problem, a problem you might not manage to get
out of unless starting all over.
Is that bug still exist on latest netbeans?
What is Pros. and Cons. between Netbeans GUI builder and Eclipse Windowbuilder?
Im using NetBeans since 6.x and never had such problems. Resizing components, adding some new, even working on the generated code etc. is realy easy and had no problem so far. Moreover NB has a visual debugger and an improved GridBagLayout customizer (both since 7.1).
Didn't use Eclipse Windowbuilder so far, but i guess its capable too. Everyone has it's own criteria for a gui builder. Btw. the author of this article seem very eclipse-focused ("on the best IDE out there - eclipse")
I'm sorry i cant give you an answer like "pro / cons of A, pro / cons of B" - as i said i've never used Eclipse Windowbuilder before. And for me there's no need to do so, i can build a gui with netbeans without problems / very easy / fast (even better than with Visual Studio). For my point of view everything works like i want it :-)
If you used both, maybe there are things you prefer or dislike on one IDE, but the other can do better.
Personally, while WindowBuilder is a pretty powerful tool to use within Eclipse, I find it more clunky (and quite honestly, prefer to write Swing GUIs by hand if this were the only optin)
Matisse is a far better option because of the Grid editors like someone mentioned previously, also I prefer the way Matisse handles event handlers over WindowBuilder. Another thing Matisse does well is that it encorporates more properties into GUI element settings where WindowBuilder goes over a very small list of changeable features (leaving you to dive through a mess of auto-generated code to change a simple property).
Eclipse does have a version of matisse available, though the plugin is not for free (look up myeclipse).
I used both Eclipse and Netbeans,
Eclipse -WindowBuilder is a powerful tool, easy to modifying it. But causes more code problems. Long time after you will get Spagetti-Codes to get solve problem.When it get problem you cant open Desing layer.
Netbeans generates codes much easy, and you can change it but more harder, sometimes you can't. But i dont get any (only a few, my mistakes) any code problems...or etc., if you get a problem about a component; you can too easy to get Default Settings any time.
Note: THAT IS ONLY MY IDEA!
While I make some (java) code, i feel the need to experiment and change some parts of it often.
I want these changes to appear in a copy of my existing project and not the original - something like "save as" vs "save".
I have some options to do this job(below). Problem is that I can't decide which one to choose.
As a beginner to version control, I want something that is very easy, but is also used in many software companies. I already have a lot of problems with compiler and run-time errors. I hope that a version control software will not make the coding process even more difficult.
Options-
1- Make copies of my code and label them with different numbers/dates.
2- Use SVN ?
3- Use GIT ?
Besides this, are there any other version control methods ?
EDIT-
Is is possible to do SVN inside eclipse itself or maybe integrate eclipse with some SVN software ? If yes, would this be a good approach ?
I currently use SVN for personal projects and Git for group projects. The way Git handles branching is pretty slick. SVN is just really easy to set up and use (you just need a URL as opposed to a ssh login on the client side).
If you're using Windows, I'd suggest using the TortoiseSVN and TortoiseGit.
https://tortoisegit.org/
http://tortoisesvn.net/
I'd also suggest not going with the first option. Revision control is pretty important, even if you're just a hobbyist.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm a Windows developer looking to do some Cocoa dev on a Mac. I'm familiar with Subversion, TFS, Sourcegear Vault, CVS and VSS in a Windows environment. What version control should I look at using in my new, unfamiliar Mac environment?
I will be doing 95% of the development, with the other 5% coming from one or two other people. However, it is probably safe to assume I will be the only one making commits.
Is there a good Subversion client for Macs? I have a repository already setup that I could use, but I also wouldn't mind using something else. What do you recommend?
Personally, I would probably just use subversion from the command line. If you are looking for a nice GUI I have heard good things about:
http://versionsapp.com/
Seeing as you're already in an unfamiliar environment,
why not go the whole hog and start using git?
Prebuilt binaries abound and for me, switching to git
this year brought me an increase in productivity.
You can also try gitx which, amonst other things,
generates nice, colourful, London metro style graphs of
of your commits and merges.
Versions is a very good Subversion client for the Mac. There are lots of other clients available too.
I personally use Git for all my Mac projects. Gitx is a good client.
I you're willing to experiment, Git, in my opinion is arguably the most powerful revision control system you can get your hands on — but it does have a small learning curve.
(You can always use the command line versions of git/svn/cvs—all of them work superbly)
Get an account at http://beanstalkapp.com/ and then use http://versionsapp.com to connect to it.
http://whygitisbetterthanx.com/
I use GIT, get it from here:
http://code.google.com/p/git-osx-installer/
Frankly speaking CVS and Subversion, others are just not good enough. People that still use them fall on 2 categories.
Because of legacy, they have to.
They are to lazy to learn something new.
Their IDE supports X.
Out of this 2, #1 is valid, if your org is already using something and the cost of change is too high, bummer, you need to take it. #2 is what happens to most people. #3 is pointless as source control inside an ide is meaningless, no real advantage/disadvantage, sure its nice, but I much rather have a better source control version than a button in my IDE.
REALLY USE GIT !.
CVS and Subversion are both available for Macs.
Subversion is installed by default on Leopard
The latest XCode knows about Subversion
so...
I agree with fraca7. Subversion support is built directly into XCode. I happen to think it's really great.
Here's a link to apple's docs on setting up svn with xcode.
As far as I remember is the SCM support in Xcode limited to git, svn and cvs.
Thus I would choose some of them.
I personally prefer subversion.
Xcode 3.1 has built in support for CVS, Subversion and Perforce. I haven't used Perforce with Xcode, but a friend does and seems happy with it. My company uses Subversion and it works reasonably well with Xcode, but it's a little rough compared to what you get with Eclipse or IntelliJ.
Beyond that, we use Subversion primarily from the command line, but my co-worker has taken a look at Versions and liked it.
XCode 3.1 has built in support for Subversion SVN.
There is a GUI plugin called SCPlugin that works very well, pretty similar to tortoiseSVN on Windows but with less frills.
Here is the link http://scplugin.tigris.org/
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a coworker who is looking to switch from InteilliJ Idea to Eclipse, and is concerned about not knowing the Eclipse set of commands.
I was wondering - would anyone have a link to keyboard mappings that can set Eclipse commands to at least sort of match Idea?
Have you made this switch? Any "gotchas", tips, or info we should be aware of?
Thanks!
I went through the experience myself - and result was a series of articles on my blog:
http://virgo47.wordpress.com/2011/01/30/eclipse-vs-intellij-idea/
http://virgo47.wordpress.com/2011/02/22/from-intellij-idea-to-eclipse-2/
http://virgo47.wordpress.com/2011/03/24/from-intellij-idea-to-eclipse-3/
http://virgo47.wordpress.com/2011/02/28/why-to-synchronize-with-svn-in-eclipse/
http://virgo47.wordpress.com/2011/04/10/from-intellij-idea-to-eclipse-4/
http://virgo47.wordpress.com/2011/06/28/from-intellij-idea-to-eclipse-5/
They are all biased towards Idea (obviously) but full of relevant Idea-Eclipse comparisons, keyboard shortcuts, little stories and observations. In generall, they are both very good IDEs, but if IDEA is 100%, Eclipse is 90%, maybe even 95% - with biggest these differences:
different mindset is needed, Projects, Modules, Workspace may mean different things or are not used at all in one or the other IDE, you have/need Perspectives in Eclipse, not in IDEA, etc...
quality of default Maven/SVN support is better in IDEA (it is also built-in), much smoother and less problems + 3way diff in IDEA is just great, generally Eclipse guys are so scared of merging - and now I understand why
IDEA is far more polished, less graphics glitches and much better default colours for highlighting, etc.
free version of IDEA does NOT have so many things as you can have with Eclipse with all possible free plugins - Eclipse plugin ecosystem is just so big!
IDEA is just way smarter in margin cases when it comes to completion, refactorings, and these other little things where IDEA was the top of the class the whole time since 2000
I was lucky I didn't have to convert in the end because we use Maven projects that work just fine in both IDEs. However I still use Eclipse for other projects (xtext).
Get the plugin from here. It seems easier to install than the one in Bartosz' answer, plus no 404s...
For the lazy: direct link to plugin
Drop the plugin jar in eclipse/plugins folder and restart eclipse. Now in preferences dialog under General > Keys you can find "Intellij Idea" key scheme.
If he definitely want to do this:
http://www.jroller.com/ervines/resource/eclipse-intellij-key-bindings.java
In answer to Bartosz, flash builder is a good reason, until jetbrains comes out with a visual mxml editor.
the direct link posted above is outdated, releases are here: http://code.google.com/p/ideakeyscheme/updates/list
Update: Found this one too: http://www.bharathganesh.com/idea-prefs.php , although it's pretty light on the description.
I could list a bunch of tips, gotchas, etc. because I've made the switch several times. I've tried to make the switch to Eclipse several times but couldn't do it and went back to IntelliJ.
First tip:
Intellj "project" -> Eclipse "workspace"
Intellij "module" -> Eclipse "project"
Second tip:
Eclipse has the concept of "Perspectives" which means it reshuffles around your UI when you're doing different things, like for debugging there's the debug perspective. I don't quite get this, I personally prefer the concept of windows, or the tool windows that dock to the bottom or sides.