I updated a projected on my SVN using Subversion on Eclipse and there was a conflict. I resolved it by removing my version and just keeping it the way it is on the server. Now whenever I commit, it says there is still conflict. In the Team Perspective, I see zero differences! How can I sort that? I don't see how it still conflicts. When committing, it says the status of that class is still conflicted.
When I update, I get "At revision 21."
Btw, I run Mac OS X so I can't use Tortoise, and I won't use versions, its expensive.
Can I just overwrite the server with my file? This is really frustrating.
Copy the modified files out, revert on the parent folder above the conflicts, move the files back in. It's a pain but it works :)
Related
Lately we had to switch at work from Subversive to Subclipse because we needed to upgrade to Java 11 and Subversive is no longer supported in recent versions of Eclipse. This has worked somewhat fine, but we're encountering problems when trying to delete files sometimes. For example, suppose you have the below Java package tree that you want to delete with no other packages or files inside the tree.
package
|---file1.java
|---file2.java
The problem I encountered is that no matter how I commit the deletion of this, it causes problems with the subsequent update by my coworkers. I have tried to commit the entire delete operation at once, and I've tried commiting the deletion of the Java files and of the package in separate commits. No matter how I commit it, my coworker ends up with his local work copy that he's updating in a broken state.
Turns out that when he synchronizes with Subversion, for some reason some of the commits get squashed in a single commit of the deletion of the package, with no deletion of the underlying java files. When he then tries to update that deletion to his local work copy, it only half deletes the files: they still remain in his Eclipse project explorer view, but they are successfully deleted in the Windows file system.
Because they remain in his Eclipse project explorer view, he gets warnings and errors related to the deleted files such as import statements that don't resolve and build path errors. However, because they are removed from the file system, Subclipse can't update them because as far as Subclipse is concerned, his local work copy is up to date! He has to recreate the files in Windows Explorer manually and then is able to override and update to fully get the changes in.
We also have the problem that some of the changes we commit, when synchronizing, appear to belong to random older commits changing that file, even if they are over a decade old, with multiple machines weirdly enough resolving the changes to different commits. Weirdly enough, a committed change often only gets partially resolved to an older commit, usually only 1 or 2 files, with the rest of the changes resolving to the recent commit.
We think these issues could somehow be related. Is this a known issue with Subclipse in certain environment? And if so, how do we fix it?
Please, help! I opened Eclipse Mars to continue coding and my code is gone! I don't know what could have caused this but it's all gone. Does anyone have any idea what can I do?
Note: I tried to right-click the java file->Replace With->Previous from local history. But a message says "No local history available for selected resource". Is there any other way?
Thank you in advance!
The first step in debugging this problem is to find out if the code is still exists without using Eclipse. Several possibilities come to mind:
The code is still where you expect, the files exist and the content is OK.
The code is still where you expect, the files exist, but the files are empty.
The workspace directory does not exist any more.
You need to use a file explorer program to find the files and check they are not empty. Try opening them with Notepad++ or similar. If you are lucky, option 1 will be the answer, and Eclipse has got confused. Just use File/Switch Workspace to set the workspace to the directory and all should come right.
Options 2 & 3 indicate you have lost data. There is probably little chance of recovery. Revert to your backups (you do have them?). Otherwise learn a lesson and set up a GIT or SVN server (or subscribe to a cloud service). I just use a very old laptop running Ubuntu with SVN server installed.
As a side issue, Eclipse does not randomly delete or empty files. There are millions of developers world-wide using Eclipse, and if it existed, such behavior would be all over the internet.
I had the same problem and found my file with a strange name in local history with this path:
".metadata/.plugins/org.eclipse.core.resources/.history/"
It was not the last version but better than nothing :)
With the Worklight/MobileFirst Studio application development for local development, I see many temporary or working files. My main issue, I may develop Java code for the server side used by an adapter and I assume that is pushed to the war file. But I sometimes don't see the change reflected. And sometimes I am working with the desktopbrowser/common web-application and I don't see those changes reflected. I may do a clean and build-all and Build All Environments.
I finally just scanned my entire Mac hard drive for those App-common and App-desktopbrowser files and found several. When I delete all of these, it looks like the working directory or cache issue is cleared up. I assume these are used internally and not documented. But I was curious if there is a clean way to delete these? Also, this is an older version of Worklight, will the same issue exist with future release? But at least I commented on directories you may not know about.
Here are the file paths that have a war file or wlapp file. Deleting these fixes my caching issue but is there a better way?
My version of Worklight: 6.2.0.01.20150430-1522
berlins-imac$ echo $TMPDIR
/var/folders/dl/abcgq/T/
Delete the wlPreview and wlBuildResources
There are cached files here:
/Users/user/Documents/workspace62LunaNewNew4/WorklightServerConfig/servers/worklight/workarea/org.eclipse.osgi/bundles
rm -Rvf ./75/data/temp/default_node/SMF_WebContainer/MyApp/MyApp/widget-resources/MyApp-common-c2713f1cefc5f5f35bec867386f2344632197fcf
cd /Users/ap123User/Documents/workspace62LunaNewNew4/WorklightServerConfig/servers/worklight/apps/myApp*
You can safely delete these folders from the TMP folder in any way you'd like.
They get re-generated everytime you open Eclipse (with Studio installed). At least that's the case in newer releases of the product.
New to Java and Eclipse. For some reason, the first time I load Eclipse on a given day, it freezes at "Initializing Java Tooling : 59%". Eventually, it gets past this and I can do my work. However, this "Initializing Java Tooling : 59%" stage takes a REALLY REALLY REALLY long time. Does anybody know why it does this or how to fix it?
You can take several thread dumps of the Eclipse Java process to see what plugins are being executed. Here is some info on how to take thread dumps.
What happen is that Eclipse loads all project configurations and then for each project it initializes all declared builders. The builder loading and initialization is what takes most of the time. Some builders need to resolve and/or reload project dependencies such as jars and other projects and also check if project resources had changed. This process can also trigger initialization of builders on other projects and it may take longer depending on 3rd party plugins you are using.
It breaks on a per workspace basis. I have had some success removing plugin data. Usually this can be found by at:-
[workspace-directory]/.metadata/.plugins
If you delete everything except:-
org.eclipse.core.resources
You will keep your projects but everything else will be deleted (preferences, scm repositories ... etc.) and will need to be recreated/reimported (you will be greeted by the welcome page, but do not be alarmed).
There is probably a specific set of plugin data that should be deleted, but this fixed my last occurence, and so I have nothing else against which to further hone in on the problem state ... for the time being.
Following mike's advice, I resurrected my workspace by just deleting [workspace-directory]/.metadata/.plugins/org.eclipse.jdt.core. That directory doesn't seem to store any important information.
I had this problem and found a solution here:
http://tedvinke.wordpress.com/2010/06/21/eclipse-initializing-java-tooling-hangs/
Here's what I did.
Rename the .projects folder in .metadata/.plugins/org.eclipse.core.resources
in the workspace folder. This doesn’t seem to affect any project and
the .project folder will be recreated when Eclipse restarts.
A more simple-minded approach than Eugene's very clever one is to remove all your plugins, one by one, keep notes, and watch performance after each removal. This should help pinpoint the plugin that's doing the big initialization. It's possible that you didn't really need that plugin after all.
In my experience, there is often a big delay associated with source control plugins because some feel the need to check project state against the repository on startup. There may be options to control this. You can also look at what kind of label decoration is in effect; if some decoration is dependent on repository state, that could be your time waster right there.
Be warned that this procedure may be destructive! You probably included those plugins for a reason, and if you remove the plugins it's possible you'll lose capabilities on already present projects, and that even replacing the plugins will not necessarily restore everything in all projects to the former state. As the disk repartition people say: We assume that you have everything backed up!
How about doing the following
eclipse.exe -clean
Just uncheck "Build Automatically" and force quit Eclipse. Then start it again.
Project>Build Automatically - uncheck
-force quit
-start Eclipse
I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.
Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:
I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.
For this specific project I have another reason not to commit the project files:
There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.
How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?
At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.
After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.
It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:
.settings/org.eclipse.jdt.ui.prefs - it contains the settings for the import ordering
.settings/org.eclipse.jdt.core.prefs - it contains the settings for the compiler version
In general I haven't noticed Ganymede modifying files without me modifying the project preferences.
I recommend to use maven so that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.
In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediately afterward." This means that we had to do some work:
Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
Create useful start up scripts for all of our relevant scenarios.
Create edited datasets that don't cause the checkout to take too much longer (it's a big project).
This philosophy was worth cash money (or at least labor hours which are almost more valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.
Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.
I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.
Try to port your project to a build system like maven. It has everything you need to get the same experience of the project on every machine you use.
There are plugins for just everything. Like the eclipse plugin. You just type "mvn eclipse:eclipse" and the plugin generates your entire ready to work eclipse project.
To give the answer to your question. Never check in files that are not being used by your project at any time in the development cycle. That means that metadata files like eclipse properties etc. should never be checked in in a SCM.
I like checking in the .project, .classpath, and similar files only if they will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)
If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do not check them into source control. It will only cause headaches in the long run.
I use IntelliJ, which has XML project files. I don't check those in, because they change frequently and are easy to recreate if I need to.
I don't check in JAR files. I keep those in a separate repository, a la Maven 2.
I don't check in WARs or JARs or javadocs or anything else that can be generated.
I do check in SQL and scripts and Java source and XML config.
I'd suggest having the actual project files ignored by the version control system due to the downsides you mentioned.
If there is enough consistent information in the project settings that there would be benefit from having it accessible, copy it to a location that Eclipse doesn't treat as special, and you'll have it available to work with on checkout (and copy back to where Eclipse will pay attention to it). There is a decent chance that keeping the actual project files separate from the controlled ones will result in loss of synch, so I'd only suggest this if there is clear benefit from having the settings available (or you're confident that you'll be able to keep them synchronised)
In our case, we used to check in the project files (.project and .classpath) to make it easy for all developers to create their project workspace. A common preferences file and team project set were located in source control as well, so creating your workspace was as simple as import preferences and import team project set. This worked very well, but does rely on everyone having a consistent environment, any customizations would have to be applied after the basic workspace is created.
We still do this for the most part, but Maven is now used so of course dependency management is handled via Maven instead. To avoid conflicting information, the .project and .classpath were removed from source control and are now generated via maven goals before we import the team project set. This would easily allow for different environments, as you would simply need scripts to generate the IDE specific portions based on the Maven configuration.
PS-For ease of maintenance though, I prefer having everyone use the same environment. Anything else inevitably becomes a full time maintenance job for someone.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization
Don't. Only check in the source code of your projects.
As a response to:
"There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard."
Eclipse offers a number of ways to keep local settings manageable: Java Classpath Variables (Java > Build Path > Classpath Variables) are one, 'Linked Resources' (General > Workspace > Linked Resources) are another http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Creating a README that states which settings to set before building/running the project works pretty well in my opinion.
Now how to make sure your continuous build system understands the changes that were made to the eclipse settings, thats another issue... (I have a separate build.xml for ant that I keep up to date by hand)