Community
Participate
Working Groups
Dear developers of Eclipse, Version: 2.1.1, 2.1.2, 3.0M6 In some situations CVS directories disappear after a certain action in Eclipse. I suggests this problem is related to the result of the structur of our build environment. This is the situation: PACKAGE_A src a.cc a.h PACKAGE_B src b.cc b.h Once the 'src''s gets a CVS directory after creating a Project from the repository (not seen in the Navigator). Suppose the sources from PACKAGE_B are dependent on the headerfiles of PACKAGE_A. Our build environment then creates in the generated build subdirectories of the PACKAGE_B a symbolic link to the PACKAGE_A/src directory. If I change/add/delete some files in one of the 'src' directories and refresh the Navigator or C/C++ Project view the CVS directories are gone and the CVS labels are set to '?'. I hope this is clear enough and there is someone who can tell me what the problem is. With kind regards
When you say "symbolic link" are you referring to an OS level symbolic link or an Eclipse linked resource? If it is the OS version, then it doesn't surprise me that the CVS directories are being deleted. The Eclipse CVS client has code that prunes orphaned CVS folders.
OK, I mean OS level symbolic links. So is there a possibility to avoid pruning orphaned CVS folders?
I have a very similar situation. The directory structure is something like src1 dir1 src2 dir2 build link to dir1 link to dir2 The build directory is in the .cvsignore file in the project root dir. After the checkout everything works perfectly, but after doing some refresh and/or synchronize with repository, some parts of the project (directories and all their files, the originals, not the links) are shown as "conficting additions". In the log there are exceptions, saying that the Entris files in the link directories are not in sync with the file system. This setup works perfectly with the command line cvs tool.
Version 2.1.3 I've encountered this problem trying to use Eclipse to work with a Linux kernel source tree. I have a source tree that I imported into CVS prior to creating the architecture specific symlinks. I then used the CVS perspective to "open as a project". Next if I run make <arch>_config oldconfig to create the architecture-specific .config and include/asm, include/asm/arch symlinks, when I refresh the project in Eclipse, the symlinks show up in the project as added dirs and the original dirs that they point to have their CVS dirs deleted from disk.
Not for 3.0
I am also seeing this happen, but cannot link it to the scenario described above - every now and again, I go to open Eclipse, usually after I've been working in it all day, and the CVS perspective opens blank.
This problem occurs at my company as well. A simple test case follows at the end. This problem arises because an internally designed build system creates a build tree which mirrors the source tree. Links ('ln -s') are created in build directories to the corresponding directory in the source tree. If a project is created using 'File->New->Projects ...->CVS-> Checkout Project from CVS' and then a build tree created, the refresh operation following these steps removes the CVS directories at the file system level. I have experienced this on Linux using SDK 3.1.0. If, for example, a source tree (created using 'Checkout Project from CVS') has the directory structure src/dir1 the corresponding build tree in our system will have the link entry bld/dir1/Lsrc -> ../../src/dir1 where '../../src/dir1' is the target of the link 'bld/dir1/Lsrc'. Following the refresh operation, the directory 'src/dir1/CVS' has disappeared. TEST CASE: This problem is easy to replicate using just a 'Simple' project. 1) Create a CVS repository from the tree src src/somefile 2) Create a 'Simple' project using the 'Checkout Project from CVS'. 3) In a shell at the project root, the file system has the structure: > find . -print . ./.project ./src ./src/somefile ./src/CVS ./src/CVS/Root ./src/CVS/Repository ./src/CVS/Entries ./CVS ./CVS/Root ./CVS/Repository ./CVS/Entries 4) At the same level as 'src', create the tree bld bld/Lsrc -> ../src (The 'bld' directory can be created via 'File->New' and the "sym" link can be created using the 'Run->External Tools' using 'ln -s'.) 5) The resulting tree, as displayed _in_ the Navigator view, will be src src/somefile bld bld/Lsrc .project 5) Following either a default refresh or a user initiated refresh, the CVS directory in src will be gone: > find . -print . ./.project ./src ./src/somefile ./CVS ./CVS/Root ./CVS/Repository ./CVS/Entries ./bld ./bld/Lsrc Note the missing directory 'src/CVS'.
I have source files from 2 cvs repositories on the same project and I when I try update from CVS using the eclipse, the CVS directories disappears too. Thanks
From the POV of a web developer, this is really quite a critical issue. Unlike other scenarios, Eclipse's linked folders feature does not really apply to web projects and symbolic links are almost always the only recourse. Assuming that the "linker" and the "linkee", for lack of better terminology, are both two different Eclipse projects, could Eclipse's Team feature discern that the linkee contains a .project file and avoid touching it / updating it altogether? I am taking the liberty of setting this to "major" as there is a loss of data due to this bug. [Update: well, I tried, but do not have sufficient privileges to do so. Could somebody else do this please?] #156828 and #82334 are probably related or duplicates. Thanks!
*** Bug 182709 has been marked as a duplicate of this bug. ***
I tried to circumvent this problem by marking directories that are OS level symbolic links as a derived ressource. Then I CVS will/should ignore these ressources. However, there are still some problemes remaining. 1.) I have to manually mark every linked ressource. This should be handled automatically by Eclipse. 2.) The derived flag is stored in the workspace and not in the .project file (see bug #150578), i.e. I loose these settings if I change my workspace or if someone else checksout this project on his computer he has to set the derived markers himself. Fixing 1) should address this problem, too. 3.) CVS does not completely ignore the derived ressources. If I go to the Synchronize View and select Outgoing Changes everything works as expected (derived ressources are ignored). But if I select Incoming Changes I will see the derived ressources (the ones I marked derived by myself). Perhaps I should fill in a new bug report for this specifically.
There is work happening to expose symbolic links in the Eclipse resource model. Once this is competed, it should be fairly straightforward to have CVS ignore symlinks.
Mass update - removing 3.4 target. This was one of the bugs marked for investigation (and potential fixing) in 3.4 but we ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
This would be important for us to have. We are developing on Embedded Linux platform. Everytime we build our platform, the make system creates symlinks so when we use Eclipse we loose 1/2 and more of our CVS directories. Recovering for such failure is not an easy task.
I have this problem as well. This sounds like the same bug as 69906.
Created attachment 132028 [details] Make it so UnifiedTree to import symlink folders from the filesystem as Eclipse linked resources. Probably not usable as-is since it is up in org.eclipse.core.resources, but illustrates one approach to solving this. Needs to convert to Eclipse LinkedResource because otherwise children of the symlink cannot be detected as symlinks. Conversion to a LinkedResource allows usage of the link caching mechanism in Project. Cross-posted to Bug 69906.
(In reply to comment #16) > Created attachment 132028 [details] > Make it so UnifiedTree to import symlink folders from the filesystem as Eclipse > linked resources. > > Probably not usable as-is since it is up in org.eclipse.core.resources, but > illustrates one approach to solving this. Needs to convert to Eclipse > LinkedResource because otherwise children of the symlink cannot be detected as > symlinks. Conversion to a LinkedResource allows usage of the link caching > mechanism in Project. Cross-posted to Bug 69906. Any news here? I would like to see this bug fixed.
The EGit team is also working on symlink support. Bug #354367 Perhaps some cooperation is possible.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
