I've been using SVN and Eclipse for development for a while, and love the strong integration between the two. However I'm now switching over to git, and understand that while the git Eclipse plugins like EGit have gotten better, they're still not as good as SVN plugins for Eclipse. (For example, there's still no submodule support, and I plan to use submodules extensively.)
I'm wondering, are there any of you who use Eclipse for development on a git project but don't use the Eclipse plugin? Meaning, you either use another git GUI client (I'm on Linux) or do everything from the command line. If so, how does this work for you?
Is it a big pain not to be able to see directly in Eclipse which files are not synchronized with the repository, etc, or is that not such a big deal? Or can I still use EGit just to see which files have changed, but make all commits and do all operations from the command line or another GUI client? If so, could anyone who's doing that describe what such a workflow might look like.
Is there any risk or problems involved with accessing one repository from multiple clients, such as command line, EGit, and multiple git GUI clients - like could it cause repository corruption because they could all change metadata at the same time? Or is it perfectly safe?
With SVN everything was simple - I never needed the command line or another GUI client for anything. Everything was possible within Eclipse. But now I'm concerned about what to expect because I really don't know how this will change my development style or if it's doable. Certainly with git being such a popular VCS and Eclipse being such a popular IDE, there are many who use both together and who can describe for me how they use it.
EGit will play fairly well with the command line git tool. I use both on linux. It's still worth installing EGit, I think, and then at least you see the status of your projects.
Sometimes you have to use F5-Refresh to refresh EGit's view of your repo, but EGit already works at refreshing the workspace with local file changes, so it doesn't come up that often.
The only other suggestion that I have is that you wouldn't want multiple workspaces to point to the same git repo. That can cause confusion.
I can't speak specifically for git, but I used to do something very similar with SVN, and I can't see any issues with doing this. Additionally, at least with SVN and Subclipse, Subclipse worked with the SVN working copy just as any other SVN client would. There are several operations that I still use the svn command-line tool for against the same projects I'm working on Eclipse. This includes things like "svn status", as well as doing batch updates of SVN properties across files (something Subclipse doesn't currently support). Other than needing to use F5 in Eclipse to perform an occasional refresh, I've never had any issues with this.
I've done very similar things with several other source control systems, and never had any issues. Especially if you just use an external client and don't worry about source control integration into Eclipse for git, I can't see that you'd have any problems, as Eclipse won't attempt to share any concern with this. I would also reommend trying EGit, as I'm guessing it will work very similar to Subclipse and not cause any significant issues. (I hope to do this soon myself.)
In terms of the workflow, in many cases - at least for an experienced developer, this should work better in some cases. In Eclipse, I often find myself switching between the Package Explorer and Navigator views to see all the files that Eclipse hides or translates by default in the Package Explorer view. Switching between Eclipse and another client really doesn't work any differently.
Related
I have been working with the same Subversion working copy as a sub-directory of my local server's htdocs folder for months now. I was working in PHPDesigner7 and managing my repository with TortiseSVN. As I am the only one working, I just commit and keep working without any real need for multiple checkouts or updates.
I recently moved from PHPDesigner7 to Eclipse for my every day IDE. I have created a project and used my working copy root as the location. I have been writing all my code in eclipse for about six weeks now, and it seems like it would be much easier to do SVN operations within the IDE. I want to start integrating SVN into my Eclipse workflow, but I want to keep my working copy in the same place it has been. There are a lot of files like Adobe Bridge index files and Docblox configuration files that I do not keep under source control, but are still important to my tools. If I create a new checkout these files will not be present. I also like being able to do local server testing directly from my working copy.
How can I use my existing working copy from within the Eclipse IDE? I have installed Subclipse, but I set my eclipse project up before I decided to try switching SVN management to the IDE. Is it as simple as making my workspace the same as the working copy? I have just been using the Eclipse default workspace. Would I be better off with a fresh Eclipse project? Are there any caveats I need to be aware of when moving from Tortise to Subclipse? I especially wonder if Subclipse does many small commit operations, or if I can continue making fewer heavily commented larger commits? Does anyone prefer the subversive plugin? If so why?
The root directory of your eclipse project should be the root of your working copy. Then you just have to right-click on the project and choose Team - Share Project, and follow the tutorial. At some point Eclipse will ask you if you want to keep the existing .svn files or not. Just choose to keep them.
The workflow in Eclipse is exactly the same as with any other SVN client. You update and commit when you want to. And you may also continue using TortoiseSVN to perform your SVN operations if you prefer. You'll just have to refresh your eclipse project after each operation.
I set up an svn repository, and got it all working. However, whenever I delete a file in eclipse, svn complains about it: Running svn st gives the line:
! filename
which seems to mean, as far as I can tell, that svn wants me to delete it with svn rm filename. However, I have no way to tell eclipse to do this. In addition, I couldn't commit until I had fixed this, which entailed creating the file again, then deleting it with svn rm.
Can anyone help?
Thanks.
Since you are working with Eclipse and Subversion, I recommend checking out some Eclipse plugins to make your life easier. I tend to use Subclipse, but you can also use Subversive. Having version control integrated into your development environment makes managing your workflow much easier, I think.
I, like many others, love Eclipse as my ide of choice, and because of the way I work (moving about, different places, different projects) want to use Git for CVS.
There is a plugin for Git in Eclipse, Egit, which is now an official Eclipse project, and currently at version 0.7.1. As I've just started using it I'm interested in how others are using it, and what work arounds they are using. Currently Egit doesn't have support for merges, so these have to be done outside of Eclipse and then the workspace refreshed.
So, How do you do this task ? (and any other tasks that Egit doesn't do right now)
Just for reference, EGIT does now support merges and uses the powerful diff interface within eclipse.
Once you have fetched the code and run a merge, if there are any conflicts they are highlighted in the project explorer with a red !, you can then right click on them and go to Team > Merge Tool, which is un-ghosted for conflicted files.
Once you have selected the code you wish to use (Either the workspace version with diff annotations in it or the HEAD version that caused the conflict) the diff window will open.
This shows your local code on the left and the conflicting code on the right, you can use the 'next difference' button to jump through all the conflicts, and the 'copy change from right to left' button to accept the remote version, or simply edit your local version in place.
Once you are happy with the changes save your file and add it, then commit the results and you should be done.
Please note I am in no way a master of git good practice, so please feel free to correct me if these are not the best operations to use, but it was an answer to the question "How do I do merges in eclipse with egit".
When working with Eclipse, I only use egit to actually commit. Everything else I do simply via the command line. The command line in git (or any other VCS) is much more superior and the software was actually created with having the command line in mind, so it's just naturally that you can access really every single feature via the command line.
Everything else only uses the command line in the background and tries to emulate a different interface, native to the host application (here: Eclipse). But by doing that you can never reach the same power as by using the original tools.
However I think when egit develops more, it might be a good way to work with git; similar to how the subversion plugin for Eclipse works well with most functions. But in my situation, I don't use Eclipse for everything and using the command line is then a lot simpler than trying to get used to multiple different plugins and the command line.
One way to work out with Egit merge conflict is to take backup of your file, delete it from eclipse, put it back from backup, Add to index and commit.
This should be done only if you can't resolve the conflict with normal Add to Index->Commit method.
PS: I assume you've already resolved the conflict manually or by using Egit merge tool, but just can't remove the conflict marker on the file.
I was intending to have a play with git, and was wondering if anyone had used the git plugin for eclipse
I see it's at version 0.3.1, and was wondering if anyone knew how stable it was / any gotchas?
Update:
If you are using a recent version of Eclipse, your Help menu has an 'Eclipse Marketplace...' link.
Enter 'git' in the Find field. This shows me EGit.
This is also very high in the Popular plugins list.
Click install. Much easier than having to add update site locations by hand.
Github blog spoke yesterday about Egit plugin:
http://freshmeat.net/projects/jgit/
I'm using if for day-to-day work and I find it stable. Lately the plugin has made good progress and has added:
merge support, including a in-Eclipse merge tool;
a basic synchronise view;
reading of .git/info/exclude and .gitignore files.
rebasing;
streamlined commands for pushing and pulling;
cherry-picking.
Be sure to skim the EGit User Guide for a good overview of the current functionality.
I find that I only need to drop to the comand line for interactive rebases.
As an official Eclipse project I am confident that EGit will receive all the main features of the command-line client.
EGit is still in eclipse incubation. You can install it using the Eclipse update manager.
Select Help -> Install New Software...
You probably do not have the JGit update URL in your list of sites so in the 'Work with:' field enter this url: http://www.jgit.org/updates
Click Add...
You should now see Eclipse Git Plugin - Integration Build (Incubation) listed as available software to install. Check it and click Next.
Click Next and agree to the license and it should be installed.
You can integrate Git-GUI with Eclipse as an alternative to EGit.
See this two part YouTube tutorial specific to Windows:
http://www.youtube.com/watch?v=DcM1xOiaidk
http://www.youtube.com/watch?v=1OrPJClD92s
It still seems barely usable, to tell the truth, especially in comparison to the CVS and SVN plugins. Is it really GIT so different that developer with four years of CVS and SVN plugin experience should be completely lost with completely different GUI, unheard commands, two or even single word error messages and "features" like overwriting the shared repository without warning? Do not use it, use command line interface. If you do not like command line interface, do not use GIT at all.
Meanwhile EclipseGit is an "Official Eclipse Technology Project" (09-05-07 GitWiki). I use the current version 0.5.0 (the Wiki is a step behind the development) from time to time, without any problems. Version comparison, commit, revert etc. is working well, although manual refresh's (F5) are necessary when using command line or other Git clients (usual and acceptable Eclipse behavior I think).
For a command line view from within eclipse, install the Aptana Eclipse Plugin, it provides you with a console. It's an incredible productivity boost if you do a lot of terminal commands.
I've set up EGit in Eclipse for a few of my projects and find that its a lot easier, faster to use a command line interface versus having to drill down menus and click around windows.
I would prefer something like a command line view within Eclipse to do all the Git duties.
egit has a serious bug when comparing a file in your working dir with an earlier - it flashes a blank tab. The bug has been around since 2010 and still has not been fixed.
This very basic feature which works very well in svn plugin is completely broken.
I've used it briefly, but it was still lacking support in several important areas (it wasn't doing renames/moves properly, or something). There also was no update site available for it.
I don't remember which version it was, but this was like 6 months ago. Hopefully it is better now.
You may be interested in these pointers: http://github.com/blog/232-github-and-eclipse
There is also gitclipse(based on JavaGit), but seems dead.
Hello is there a way to use svn command line from eclipse?
Within eclipse in my project browser i can righclick and then click team and than i have something like svn. Not sure which plugin it is. But it doesn't have button's to for example ignore files for uploading. That's why I want to to it command line. And my question is how to do it.
Ok so how can I use it from command line in windows xp?
The plugin you are probably using is Subclipse. It should have an "Add to svn:ignore" option. If not, try updating to the latest versions of Eclipse and Subclipse. In general subclipse should be enough and there is no need for the command line.
For Windows XP I recommend Tortoise SVN. It integrates with the Windows Explorer and offers you a graphical environment for all your needs. I would say that is much more stable than subclipse and very easy to use.
If you do want to use the command line tools, download and install svn-win32 from here. The command line tools could be helpful in merge and copy operations.
I should also point out that none of these methods interfere with each other. You can work with Tortoise SVN or the command line and subclipse won't be affected. All svn clients work by writing and reading from hidden directories called .svn. There is one such directory in every folder under source control. As long as the svn client software is of the same version, an svn client can write to these hidden folders and another one will be able to read from it. A problem could arise if one of the clients is updated to a version that uses a different protocol for writing to the .svn folders. In that case, older clients won't be able to read the information stored there. Upgrading them to the latest version will solve the problem.
Not sure what you're trying to do; sometimes it's better to describe the goal rather than the means you plan to do it.
Have you tried Subeclipse? It lets you use SVN inside Eclipse; it's great.
I'm not sure if you can use it from Eclipse, but nothing stops you from just using it. From cmd / xterm / whatever. It's not going to interfere with Eclipse in anyway, nor will it interfere with Subclipse (which I'm assuming is what you're using).
I'm using subclipse, and in generaly it works pretty well.
However, and I guess this is your problem, the Team Synchronization by default wants to add all files in my projects, not just the ones I add to version control. This is lame and frustrating, and apparently there's no way to turn it off. Screenshots for older versions, however, hints at the possibility of turning the "feature" off. Frustrating!
I'm not personally a fan of Subclipse - it slows the IDE a bit too much for my taste. Here is an alternative approach using External Tools and TortoiseSVN
Create a new External Tool
Call it SVN Commit
Set the Location to \bin\TortoiseProc.exe (mine is C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe)
Set the arguments to /command:commit /path:"${selected_resource_loc}"
Open the file / directory you want committed and run the external tool.
Interchange the commit in step four for additional commands. You can also add the specific tools to favorites and have them in a dropdown on the toolbar.
Additional Arguments Here
Not intended to be too presumptuous here, but I think you should look at whether Subversive or Subclipse actually solves problem in a different way than you intended. For instance, it is very much possible to ignore files and directories from being checked in, via Subclipse.
On the other hand, if you really want to hack away via the command prompt from Eclipse, you must install the Target Management project (supported for Eclipse Europa and Ganymede). Once you have that installed, you can launch a remote shell to your local machine and then type away on the command line :).
PS: I haven't used this approach ever; Subversive satisfied all my requirements of a SVN plugin in Eclipse.