Community
Participate
Working Groups
Immediately after finishing to perform a merge, while on the Team Synchronizing perspective, I got the following error. Please note that a conflict on .project occured as a consequence to the merge operation: Version: 0.7.9.I20111123-1700 SVN Client: org.eclipse.team.svn.connector.svnkit16 2.2.2.I20111119-1700 SVN/1.6.17 SVNKit/1.3.6-v1 (http://svnkit.com/) r7998_v20111004_1436 JVM Properties: {java.runtime.name=Java(TM) SE Runtime Environment, java.runtime.version=1.6.0_26-b03, java.vendor=Sun Microsystems Inc., line.separator= , java.class.version=50.0, os.name=Windows 7, os.arch=amd64, user.country=IT, os.version=6.1, eclipse.commands=-os win32 -ws win32 -arch x86_64 -showsplash -launcher D:\Eclipse37\eclipse.exe -name Eclipse --launcher.library D:\Eclipse37\\plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502\eclipse_1406.dll -startup D:\Eclipse37\\plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar --launcher.overrideVmargs -exitdata 1f88_5c -data d:\workspace37-custom-reve -vm C:/Program Files/Java/jre6/bin/javaw.exe , java.version=1.6.0_26, osgi.framework.version=3.7.1.R37x_v20110808-1106, file.separator=\, java.vm.info=mixed mode, path.separator=;, user.timezone=Europe/Berlin, user.language=it, java.vm.name=Java HotSpot(TM) 64-Bit Server VM, file.encoding=Cp1252} org.eclipse.core.internal.resources.ResourceException: Errors occurred while refreshing resources with the local file system. org.eclipse.core.internal.resources.ResourceException: Errors occurred while refreshing resources with the local file system. at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.java:923) at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:904) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1657) at org.eclipse.team.svn.core.operation.local.RefreshResourcesOperation$2.run(RefreshResourcesOperation.java:131) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.team.svn.core.operation.local.RefreshResourcesOperation.doRefresh(RefreshResourcesOperation.java:129) at org.eclipse.team.svn.core.operation.local.RefreshResourcesOperation$1.run(RefreshResourcesOperation.java:106) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.operation.local.RefreshResourcesOperation.runImpl(RefreshResourcesOperation.java:96) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.findChanges(AbstractSVNSubscriber.java:314) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber$UpdateStatusOperation$2.run(AbstractSVNSubscriber.java:349) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber$UpdateStatusOperation.runImpl(AbstractSVNSubscriber.java:347) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:81) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.refresh(AbstractSVNSubscriber.java:186) at org.eclipse.team.svn.core.synchronize.MergeSubscriber.refresh(MergeSubscriber.java:129) at org.eclipse.team.internal.ui.synchronize.RefreshSubscriberParticipantJob.doRefresh(RefreshSubscriberParticipantJob.java:116) at org.eclipse.team.internal.ui.synchronize.RefreshParticipantJob.run(RefreshParticipantJob.java:309) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Contains: Failed to read the project description file (.project) for 'SuiteCardinis'. The file has been changed on disk, and it now contains invalid information. The project will not function properly until the description file is restored to a valid state.
I know about the problem but have no idea how to avoid it, since the error is caused by the conflict between SVN merge/update and Eclipse IDE project support concepts. The only idea I've got is to search for the ".project" entry in the error message then ignore the error if ".project" is found.
Isn't there a way to avoid the merge operation to change the .project when a conflict occurs, while letting the user do the manual merge in those circumstances? I know it has to be problematic... but I was thinking to something like the merge operation in CVS, where the local files aren't actually changed until the user does the merging operation. However, I fear this is not under Subversive control, but rather is the SVN connector responsibility... Anyway, one thing is certain: when merging, changes to the .project/.classpath files often lead to conflicts, even in circumstances where the changes are quite elementary and I would expect SVN to resolve them automatically. I don't know if something could be done in this area. Filtering out the error message and providing a more user-friendly message (like: "Warning: the merging operation has caused conflicts on Eclipse project metadata (.project file). It is recommended that you resolve these conflicts before anything else before continuing") could be the last option indeed. Another idea would be to ask for ideas to the Eclipse Team API/eGit dev team: I think this problem must have been faced by them, too.
(In reply to comment #2) > Isn't there a way to avoid the merge operation to change the .project when a > conflict occurs, while letting the user do the manual merge in those > circumstances? Unfortunately it's not possible for the merge process. Quite a time ago we've tried to implement it on the plug-in level (the code is still there), but it wasn't stable solution due to not all required information available on that level and, at the same time, guys who works on SVN/SVN Kit does not seem to be interested in changing the client side support for merge. Asking CVS/Team guys is also meaningless (in fact, AFAIR, I've asked them once for something related to SVN specific and got "redo SVN client from the scratch" as the answer) since they have their own implementation of CVS client (no wonder, in the end CVS is much simpler than SVN) where they can do anything they want. On the other hand - we have no actual resources to study and reimplement SVN client library. There is also this reason why I haven't hidden the error message yet: there are more to it than just the problems with ".project" file, there are more files that can cause the issue (content of the ".settings" folder etc.). So, in my opinion it is really the SVN client fault... but still, what we can really do?
(In reply to comment #3) > Asking CVS/Team guys is also meaningless (in fact, AFAIR, I've asked them once > for something related to SVN specific and got "redo SVN client from the > scratch" as the answer) since they have their own implementation of CVS client > (no wonder, in the end CVS is much simpler than SVN) where they can do anything > they want. On the other hand - we have no actual resources to study and > reimplement SVN client library. I see. And what about the eGit guys? I don't know Git, but I think it's much more complex than CVS and I know they're actively working on eGit lately. Maybe they've faced similar problems, too... or do they have written the Git client from scratch? By the way, one advantage of Eclipse SVN integration against the CVS one is that it's perfectly compatible with other SVN clients (while this is not 100% true for CVS). So it's reasonable that the better approach is to try to solve these corner cases rather than trying to "reinvent the wheel". > There is also this reason why I haven't hidden the error message yet: there are > more to it than just the problems with ".project" file, there are more files > that can cause the issue (content of the ".settings" folder etc.). > > So, in my opinion it is really the SVN client fault... but still, what we can > really do? I think the best that can be done is to collect cases, try to identify when errors caused by those cases occur and provide a handled warning message that tells the user what's happened and what he/she should do, instead of leaving the default "unexpected error" message. In this way: - you avoid the user to think that Subversive/Eclipse is buggy - you avoid the user to file duplicate bug reports like this one - you advice the user to fix those errors immediately (I don't want to think about what could happen if the user restarted the IDE before resolving such conflicts...) We can start by considering these cases: - .project conflicts - .classpath conflicts - .settings/** conflicts If there will be other cases like this one, the generic error message may lead people to file new bug reports and the new cases may be handled as they are found. What do you think?
(In reply to comment #4) > I see. And what about the eGit guys? I don't know Git, but I think it's much > more complex than CVS and I know they're actively working on eGit lately. Maybe > they've faced similar problems, too... or do they have written the Git client > from scratch? I actually don't know, but if Git API allows to perform merge in "Eclipse-like" manner, then there is no need to reimplement anything > I think the best that can be done is to collect cases, try to identify when > errors caused by those cases occur and provide a handled warning message that > tells the user what's happened and what he/she should do, instead of leaving > the default "unexpected error" message. In this way: > - you avoid the user to think that Subversive/Eclipse is buggy > - you avoid the user to file duplicate bug reports like this one > - you advice the user to fix those errors immediately (I don't want to think > about what could happen if the user restarted the IDE before resolving such > conflicts...) > > We can start by considering these cases: > - .project conflicts > - .classpath conflicts > - .settings/** conflicts > If there will be other cases like this one, the generic error message may lead > people to file new bug reports and the new cases may be handled as they are > found. > > What do you think? I think you're right. I'll make this report into the task regarding error handling.
*** Bug 369310 has been marked as a duplicate of this bug. ***
*** Bug 372460 has been marked as a duplicate of this bug. ***
*** Bug 382668 has been marked as a duplicate of this bug. ***
*** Bug 382459 has been marked as a duplicate of this bug. ***
*** Bug 387355 has been marked as a duplicate of this bug. ***
Done.
I verified this is working correctly in 1.0.0.I20121013-1700, thank you! :-)
