Subclipse leaves files out of sync after checking out

[g***@ca.ibm.com]

Eclipse: 3.4
Subclipse: 1.4.7 (org.tigris.subversion.subclipse.core_1.4.7.jar)

We have a product based on Eclipse. A customer reported an issue while using Subclipse with our product. We have a piece of code that writes to the project preferences to indicate that the project is configured to a certain level of our product. This information is stored in the ".settings" folder of the project. When a project is added to the workspace, this information is looked at to determine if it needs to be migrated. However, the resource tree is out of sync immediately after checkout using Subclipse, so it doesn't get the proper information returned and thinks that the project needs to be migrated. I've attached a sample plug-in (a workspace project, not a deployable plug-in) that demonstrates the behaviour I'm talking about. The plugin attaches a workspace listener on early start up. When a project is added to the workspace, it determines if the migration flag is set. If not, it sets it. Output is printed to the console to indicate what it finds. Here is a scenario using the plug-in:
- create a simple project (note that "migrator" runs and sets the flag, file exists in .settings folder)
- share the project with SVN using Subclipse
- commit all files in the project
- delete the project from workspace
- checkout the project from SVN
When the migrator runs, it doesn't read the preference properly (even though the file is on disk). Debugging shows that the project resource hierarchy is out of sync with the file system. During debugging, if I force the project to be refreshed, then it works properly. In my opinion, Subclipse should leave the workspace in happy/synchronized state after the workspace runnable is finished that creates the files. Note that I do see some "SVN" threads running when the migrator job is running into the synchronization issue. The SVN threads are waiting on the workspace lock which the migrator job is holding.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=986007

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Mark Phippard]

Post by g***@ca.ibm.com
Eclipse: 3.4
Subclipse: 1.4.7 (org.tigris.subversion.subclipse.core_1.4.7.jar)
- create a simple project (note that "migrator" runs and sets the flag, file exists in .settings folder)
- share the project with SVN using Subclipse
- commit all files in the project
- delete the project from workspace
- checkout the project from SVN
When the migrator runs, it doesn't read the preference properly (even though the file is on disk). Debugging shows that the project resource hierarchy is out of sync with the file system. During debugging, if I force the project to be refreshed, then it works properly. In my opinion, Subclipse should leave the workspace in happy/synchronized state after the workspace runnable is finished that creates the files. Note that I do see some "SVN" threads running when the migrator job is running into the synchronization issue. The SVN threads are waiting on the workspace lock which the migrator job is holding.

Care to supply a patch?

We keep Eclipse in synch based on notification we receive from SVN.
We run a checkout API provided by Subversion. This API makes
notification callbacks that tell us about files and folders it
creates. This is what drives the output we place in the Console view.
As part of these notifications we also notify Eclipse about the same
changes.
--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=986057

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[p***@tigris.org]

So I assume that each notification you receive from SVN results in a separate synchronization call to the workspace. Does the set of notifications have a "start" and "end" call? I ask this because if you knew when SVN was done checking stuff out, then you could wrap everything in one workspace runnable and do something like:

Workspace.run(theOp, workspaceRoot, IWorkspace.AVOID_UPDATE, someMon);

I put the AVOID_UPDATE flag in there so resource change listener are not called until the project has settled. This will make the entire operation more atomic.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=986746

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Mark Phippard]

Post by p***@tigris.org
Workspace.run(theOp, workspaceRoot, IWorkspace.AVOID_UPDATE, someMon);
I put the AVOID_UPDATE flag in there so resource change listener are not called until the project has settled. This will make the entire operation more atomic.

The SVN notifications do not have an explicit start and end but we
know when it starts and when it end. We relay the notifications to
Eclipse and it relays them back to any listeners, including us. So
our code that processes the status updates actually gets them from
Eclipse not SVN. I've not worked with this code myself in depth, but
that is my understanding.
--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=986768

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Grant Taylor]

I finally got some time to pull down the Subclipse code and do some debugging. From what I see, org.tigris.subversion.subclipse.core.commands.CheckoutCommand is supposed to be doing the "atomic" operation of checking out the project. Through my debug session, it seems like the file and folder retrievals are already done in an atomic fashion using the SVN API. The only thing missing, in my opinion, is that the Eclipse "IResource" side of the equation is not attempted to be brought into sync after the retrieval. I put the following lines in the basicRun() method, right after the checkoutProject() call:
...
checkoutProject(pm, resource, svnClient, destPath);

<grant taylor change>
if(project.isAccessible())
{
try
{
project.refreshLocal(IResource.DEPTH_INFINITE, new NullProgressMonitor());
}
catch(CoreException exc)
{
throw new SVNException("Cannot refresh project after checkout", exc);
}
}
</grant taylor change>

// Bring the project into the workspace
if (refreshProjects) refreshProject(project, (pm != null) ? Policy

The above lines bring the project into a consistent state, with all resource in sync.

I believe leaving the project with many out of sync resources is not good practice, so the above synchronization should be done.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1059663

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Grant Taylor]

This issue has recently come up again with another customer. In this case, they were on the 1.6.x server and client. I debugged the issue again and found the exact same root cause. The SVN project checkout code needs to leave the workspace in a synchronized state *within* the workspace modify operation. The listener mechanism that is currently implemented leaves windows for other components to receive incorrect preference values.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2741514

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Mark Phippard]

This issue has recently come up again with another customer.  In this case, they were on the 1.6.x server and client.  I debugged the issue again and found the exact same root cause.  The SVN project checkout code needs to leave the workspace in a synchronized state *within* the workspace modify operation.  The listener mechanism that is currently implemented leaves windows for other components to receive incorrect preference values.

Thanks. There is some information on how to submit patches here:

http://subclipse.tigris.org/wiki/SubclipseDevelopment
--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2741515

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].