I've been working with branches for quite some time now, but I always used command-line tools to do the actual merging. However, now I need to do it from Eclipse only. Branching and merging being a widely used feature of SCM systems for many years now, I expected Eclipse to have good had support for it, but it just doesn't seem to be the case.
Currently I'm working on a product that is built up of several projects that need to be branched together. When merging changes from trunk to a branch, normally I would execute the following from the root of the branches checkout: (I'm using Subversion as an example here, but the problems should apply to other SCM tools as well.)
svn update
svn merge ^/trunk
svn commit -m "Merged from trunk"
Maybe fix some conflicts in the middle, but that's about all I have to do. However, in Eclipse I can only merge on the project level, which has the following disadvantages:
I cannot merge the contents of the root folder, only the contents of the individual projects. Same goes for updating, BTW.
If the project structure is modified on trunk (e.g. a new project has been added), those changes don't get merged at all. Same for update, again.
The merge is not atomic. If a commit happens on trunk during the merge, things can get messed up in my working copy. (This can be worked around, but not conveniently.)
These limitations seem pretty straightforward from the fact that Eclipse does not know about the root folder, as it checks out individual projects from SVN.
My question is: am I missing something, or is it really impossible to use Eclipse in a way similar to what I'd do from the command line? And if it is indeed impossible, then how do others cope with this? Does everyone use external tools like the command-line, or TortoiseSVN?
Your observation is correct. Eclipse manages "team" operations like svn on project level only. So, you're not missing anything ;-)
Yes, you have to use external tools for merging whole branches. Tortoise does it nicely.
Multi-project merging can be done with the Eclipse plugin CollabNet Subversion Merge Client. You can find it at com.collabnet.subversion.merge.
Enable it in the preferences:
Eclipse Preferences > Team > SVN > Diff/Merge
and there: Merge Implementation: CollabNet Desktop
What you mention is indeed a limitation. I normally checkout the whole folder structure and then import the individual projects into eclipse. When I need to do an operation on the whole repository, I do it outside from eclipse using either the command line or Tortoise SVN.
It is also a pain, that when someone adds a new plug-in (I am developing an Eclipse RCP application), I need to manually add it to the project list as Eclipse does not know about the root of all the projects.
In Eclipse, SVN branching and merging works nicely for single projects, I have not had any issues when dealing with single projects that have been branched and need to be merged.
However, if multiple projects need to be dealt with a single unit, then this does not seem to be possible to deal with directly in eclipse, each project would need to be dealt with individually.
Related
Is there any build tool like maven,gradle support to build only staged/committed code not to include unstaged/untracked file.
Basically while development some scenarios arise in middle I want to check what committed package vs uncommitted one.Though I can achieve two different directory but such flexibility in any build tool will help a lot.
Ex: Consider I have one maven project I modified and committed & pushed the code to GIT Repo.Later I started my further development.When I do build, it builds including all the files but I wanted to know If there is any way I can skip the unstaged/untracked files in maven pom.xml to build only committed files.Any plugin like that which helps to achieve this or any other build tools.
I think git stash comes in handy for this:
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Something I use and find very convenient is particular Source Code Management plugin for Jenkins, see complete list of similar here. In my case I use Git plugin, which provides Refspec configuration property. I put there either committed or uncommitted changes' refspec. The build uses source code built until the change pointed in the refspec. Due to my understanding - this is exactly what you need.
P.S. I also build with maven, even though this doesn't matter for this case.
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I love being organized, and I hate having all my java projects in eclipse right in the workspace. It makes it very cluttered, and I wanted a more organized approach, where I have folders in my workspace for different kinds of projects. However, folders can only be added into other folders, and not the workspace itself. Also, I wanted a way to be able to put classes into just any folder, and not just the src folder in a project. I love eclipse, but I really want the way to organize my programs to be a little more flexible. Does anyone know how I can do this?
I think what is organized to 1 person is not the same for another. I have found some of these techniques helpful maybe they will help you
Group projects to working sets so you do not see the full workspace
You can keep sources in different folders add those source folders in the build path
Use tools like Collabnet that integrates with your version control repository and issue management systems like JIRA and at given point in time you can view only the files that are relevant to the issue you are working with.
Know your keyboard shortcuts very well
For what I understand, you are formulating two expectations:
Have a clear directory structure for your projects, independent from the IDE;
Have a clear workspace organization, which reflects the underlying structure of your projects.
There is something you did not mention, which is the build facility for your project. I guess you are compiling and running your projects from within Eclipse? If not, or if you are willing to compile, test, deploy and run your project besides your Eclipse IDE, you can have a look to full-featured tool like Maven.
The point is that even if you do not want to build your project outside of the IDE, this tool will save you so much time that it is even worth to use it only to have a clear, proper, conventional and understandable directory structure as you seem to expect. On the other hand, the problem is that such a tool addresses issues that are far beyond your own requirements, which may render it overkill to use for the sole purpose exposed above.
Maven is a perfect tool for those who like to be organized. One of its core concept is convention over configuration.
This means, for instance, that if you follow Maven conventions for your projects, the simple command
mvn eclipse:eclipse
will generate for each of your them a corresponding Eclipse project, which you will be able to configure, generate and clean from outside Eclipse.
I have two computers, and want to share a java project in eclipse by saving and opening the project from my USB stick.
But I can't seem to get it to work very easily.
What steps do I need to take to set this up properly?
These things should be discouraged. My advice is using an SCM (Source Control Management)
like Git and keep a repository on the external drive (if using Git, a bare repository on the USB stick and a local repository on each machine). At the beginning you'll spend quite some time getting used to, but it will pay soon (you'll have descriptive changelogs and disaster recovery facilities)
Eclipse has support for Git via Egit, and for SVN builtin.
When you share a project like this, you may encounter troubles related to classpath references to external JARs, which may be overcome by
using a lib/ folder (thus keeping the JARs under version control)
using an environment variable like $JAVA_LIB
using some dependency manager like Maven or Ivy (again, there are lots of stuff, but will pay even in the short term)
For existing project that you don't want to put under version control, you can simply (again, there may be missing library errors) use the menu File > Import > General > Existing projects into workspace
I strongly recommend using a cvs, svn, or other version control repository for this purpose. Trying to manage it manually is eventually going to bite you.
But if you insist, the best way I know of is to create the project in Eclipse by un-selecting the Use Default Location option in the New Java Project wizard. That allows you to specify an external location for the project contents, in your case the USB drive. You'll have to make sure of a few things:
that the USB drive is always plugged in while Eclipse is running.
Refresh the entire Project each time you move the USB drive from one computer to the other.
Any references to JARs are either internal to the project (eg, in a /lib folder inside the project) or use Classpath Variables.
It's going to be quite tedious, which is why it's always recommended to not try this and use a version control repository instead.
I do this. With some projects I have in SVN or GIT. For me it's more important to have only one eclipse and one workspace. Unfortunately this limits to Windows (or one os). The trick is to ensure that it always has the same drive letter. I tried with subst first, but I forgot to often. But using the drive manager from Windows everything works fine.
I am working with a team environment with a heterogeneous blend of IDE's among different developers. Some use Eclipse, others NetBeans, others IntelliJ, etc. The code projects are all structured around Maven... so nobody cares which IDE you use as long as it can play with Maven.
To that end, we're not supposed to commit any IDE-specific files (e.g. ".project", ".classpath") to the CVS repository. I believe that this second part may be overkill... but we're also not supposed to commit our ".cvsignore" files, which contain filters for our individual individual IDE-specific files.
It's a bit of a hassle dodging around my ".cvsignore" files every time I sync with the repository. Is there a way that I can prevent Eclipse from displaying those files in the "Team Synchronizing" perspective?
You can add patterns to Window -> Preferences -> Team -> CVS -> Ignored Resources. This should cause Eclipse Team CVS to ignore the file when commiting.