Community
Participate
Working Groups
Steps to recreate seem to be the best way to describe this issue: 1. Create a project in the workspace 2. Create a folder in the new project, link the folder using linked resources to a directory in the file system. 3. Checkout a module from CVS into the folder created above. (At this point, I can do a "Synchronize with repository" on the project and the result is, as expected, a message saying that there are no differences.) 4. Exit the Eclipse. 5. Start the Eclipse. 6. Check the properties of the project, the CVS information looks ok. 7. Check the properties of the folder, and the CVS section of the Properties dialog says "This folder has lost its sharing information" If the folder created in step 2 was not a linked folder but a folder right under the project folder, the CVS sharing information doesn't get lost. I have chosen the severity of this issue as "critical" because at this moment, if I want to use Eclipse's CVS functionality, I can't keep files from/for CVS out of the workspace directory. Build used is 20030806
OS Info: SuSE 8.2 with Gnome Eclipse with Motif UI
I have changed the priority because this is a serious usability issue and hasn't been look after at all since it was opened. Additional info: The properties panel of the linked folder informs that the CVS information has been lost, however, the CVS files on the file system are exactly same as they were right after the files were checked out.
Repository providers in Eclipse ignore content that is contained in linked folders. To use a module from CVS as a linked folder and still be able to perform CVS operations on the module, you must do the following. 1) Load the module as a project P1 2) Link the folder f1 in P2 to P1 You can then perform Team operations on P1 and f1 will be updated as well. I know this is not ideal but it is a restriction of the current architecture. The bug in your workflow was that you were able to checkout content from CVS directly into a linked folder. This should not be permitted. Bug 35011 already reports this problem. *** This bug has been marked as a duplicate of 35011 ***
I do not agree that checking out into a linked folder should not be permitted. If the current infrastructure does not allow for it, then a bug has to be opened to address this issue of the infrastructure. So far, I was able to use linked folders the same way as I use non linked folders and I see no point for CVS to be different. If the checkout and synchronize works correctly within the same session, but doesn't after restart, than it looks to me like the problem is in re-initialization of the sharing infor after the Eclipse restart.
WE gave you a workaround, changing the severity to enhancement becauwe it's basically a change in the architecture. During the linked resource work by the platform team a decision was made to not force repository providers into supporting linked resources. It may not have been the best decision, but nevertheless there are workarounds.
Changing this into the request for CVS to traverse into linked resources
*** Bug 77425 has been marked as a duplicate of this bug. ***
*** Bug 36685 has been marked as a duplicate of this bug. ***
*** Bug 82689 has been marked as a duplicate of this bug. ***
*** Bug 102056 has been marked as a duplicate of this bug. ***
*** Bug 35011 has been marked as a duplicate of this bug. ***
Bug 35011 mentiones that you can checkout into a linked folder but, after a restart, you cannot perform updates on the linked content which is consistent with comment 3. There is currently no plan to address this issue.
I currently have a problem w/ the suggested workaround. I used linked resources to avoid the I/O cost of scanning too many directories (e.g., say project P1 has 4000 files, of which I only want to include/compile 100 files in a select few packages/folders). Is there any workaround that will enable me to: (1) achieve the same I/O savings [by using linked resources] (2) use CVS/SVN plugin to manage the revisions of files [in the linked resource] ? If not, could the priority of this bug be re-escalated again? Thank you.
For Java, files can be exclude from compilation on the Source tab of the Java Build Properties of the project and indicate which files and packages should be excluded from compilation. However, this may not solve all the I/O performance issues. Unfortunately, we just don't have the manpower to work on this issue.
Since RESOLVED LATER is deprecated, can we get this reopened?
I'm reopening the issue for two reasons. RESOLVED LATER is deprecated :-) and people are again interested in this bug.
Created attachment 147046 [details] Patch to support linked resources Here is a patch to support projects with linked resources (and groups - a 3.6 feature- , incidentally). With this patch, the user can now have linked resources folders and files in a project, and use all cvs operations - add, commit, update, tag, branch, remove, annotate, log - on them transparently. Naturally, the linked resources that point to files and folders outside the project directory are not themselves checked out by the project checkout mechanism, but are expected to exist on the local cvs repository nonetheless. The only main limitation is that all linked resources in the project have to share the same CVSROOT as the other files, but files can be located on different cvs modules. In terms of the implementation, the main new features that the patch adds is: 1) The ability to perform cvs repository operations (get/setSyncBytes(), get/setFolderSyncInfo(), etc...) on files outside of the workspace, i.e. not representable by a IResource object, but by a IPath only. 2) The multiplexing of a single cvs operation into multiple ones for each local root, depending on the file system structure of the selected resources in the workspace (implemented in LocalRootRunnable). Finally, this patch only depends on 3.6 for a single method in the EclipseTest.java method, and could be removed without much consequence. The way the cvs plugin supports groups (a 3.6 core resource concept), is by gracefully supporting linked resource folders that return null for IResource.getLocation(), so it's backward compatible, and supports groups automatically. I'm not an expert with the cvs plugin, and I'm sure that there are things that I overlooked, but the patch does work, and it does add the ability to support projects with linked resources. I would be grateful if someone knowledgeable of the cvs plugin could review it. Thanks.
I need to update the patch so that it is synchronized with the 3.6 sources.
This sounds really neat Serge! (In reply to comment #17) > The only main limitation is that all linked resources in the project have to > share the same CVSROOT as the other files, but files can be located on > different cvs modules. I solved this here for a local fix to bug 153408. Some of our projects are built by checking out a number of source folders from different repositories to build the application. I did this by having multiple workspaceRoots in CVSTeamProvider which provides utlility methods to get the root for a given IResource. A CVSWorkspaceRoot is then any IResource whose parent isn't in CVS. We had to disable the *evil* code that prunes 'unparented' cvs directories. Loads of little changes were required to cvs.ui to use IContainer rather than IProject, and the sharing wizard was tweaked to hunt through the project until the roots could be found. It sounds like your approach is more flexible in that any container can be mapped to any repository location.
(In reply to comment #18) > I need to update the patch so that it is synchronized with the 3.6 sources. Have you managed to synchronize the patch with 3.6 sources? Any suggestion on how to apply it?
Created attachment 174615 [details] Patch to support linked resources Here's an updated patch for the 3.6 sources (from head)
(In reply to comment #21) > Created an attachment (id=174615) [details] > Patch to support linked resources > > Here's an updated patch for the 3.6 sources (from head) Thanks. Any suggestion on how to apply this patch? What's going to happen if I update Eclipse after applying a patch?
(In reply to comment #22) > (In reply to comment #21) > > Created an attachment (id=174615) [details] [details] > > Patch to support linked resources > > > > Here's an updated patch for the 3.6 sources (from head) > > Thanks. > Any suggestion on how to apply this patch? > What's going to happen if I update Eclipse after applying a patch? Hum, I'm not sure I follow you. The patch has to be applied when you have the 3 plugins in the workspace: org.eclipse.team.cvs.core org.eclipse.team.cvs.ui org.eclipse.team.tests.cvs.core If you want to actually use those plugins, you have to first - get the sources, apply the patch, then export them as .jar files, then install them in your dropins or plugins directory, and make sure they are loaded instead of the ones installed in your layout.
(In reply to comment #23) > If you want to actually use those plugins, you have to first - get the sources, > apply the patch, More on patching here: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-68c.htm > then export them as .jar files, then install them in your > dropins or plugins directory, and make sure they are loaded instead of the ones > installed in your layout. Or you can export the patched plug-ins and install them into host[1]. AFAIK they won't be updated next time you update the Eclipse. [1] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/export_wizards/export_plugins.htm
Serge, Tomasz Thanks for help. What's the chance of this patch getting into Eclipse?
(In reply to comment #25) > Serge, Tomasz > > Thanks for help. > > What's the chance of this patch getting into Eclipse? This improvement is scheduled for 3.7, see: http://wiki.eclipse.org/Workspace3.7
(In reply to comment #19) > This sounds really neat Serge! > (In reply to comment #17) > > The only main limitation is that all linked resources in the project have to > > share the same CVSROOT as the other files, but files can be located on > > different cvs modules. > I solved this here for a local fix to bug 153408. >(...) > We had to disable the *evil* code that prunes 'unparented' cvs directories. (...) > It sounds like your approach is more flexible in that any container can be > mapped to any repository location. I'm really looking forward for a patch that includes both James's and Serge's, and also take into account nested projects because right now their CVS folder gets deleted! See bug #156828. James, is there patch available somewhere for what you described in your comment #19?
Created attachment 207795 [details] Updated patch for CVS trunk
Why hasn't this patch been checked in yet?
(In reply to comment #29) > Why hasn't this patch been checked in yet? Because it is pending review.
Created attachment 208313 [details] Updated patch for CVS trunk
(In reply to comment #30) > Because it is pending review. More than 2 years for a review? Maybe you missed to set the review flag for this bug?
So the review didn't happen in time for Eclipse 3.7. Is this going to make 3.8? I have customers beating me up over this. While that may be fun to watch I really need to get them a solution. The workaround is not very popular.
Unfortunately, 3.8 (Juno) is already out... :-( Any feedback from the Eclipse devs?
The last update I got is that someone from the core.resources team was scheduled to take a look at it. We've been using this patch with a custom build of the CVS plugin for years for our customers.
Do you happen to have the jars for 3.7/3.8 that I could give a try? I am an apps support guy so I am not familiar with how to build them from the supplied source patch. Thanks, John
(In reply to Serge Beauchamp from comment #35) > The last update I got is that someone from the core.resources team was > scheduled to take a look at it. > > We've been using this patch with a custom build of the CVS plugin for years > for our customers. Serge, do you happen to have an up-to-date patch for eclipse 4.3 or 4.4?
once again, more than a year is gone. is there any usable solution for this problem?
