Community
Participate
Working Groups
There already exists a general project with CVS connected, named as "phone". Now, Checkout a new general project, named as "addrbook". Use command line terminal to create a soft link to connect the root of project "addrbook" to a new folder "addr" in project "phone". The command in Windows 200 would be: *\phone\> linkd addr ..\addrbook (Require Windows 2000 Resource Toolkits) Or in linux box, use "ln -s ...". Now, refresh the project "phone", a new folder of "addr" will be displayed. But after "refresh" action is performed. Now refresh project "addrbook", all the CVS information is gone. Check the file system, CVS folder and sub CVS folders under addrbook are deleted. I don't think refreshing a folder/project have the right to remove those CVS folders quietly if they are detected as implicitly checked out (linked folder) into the project. BTW: Check out a CVS project into an existed CVS project and refereshing that folder does not remove anything about CVS, which is correct. And Eclipse's link folder is not tested in my case.
This problem also occurs when the project have 2 or more src dirs from different CVS roots.
When you say "linked" you mean the OS version of that correct? There is the notion of linked folders at the Eclipse level and CVS makes sure not to purge the CVS folders from that type of link. If we had the ability to determine if a folder was an OS link, we could avoid purging in that case as well. John, did I hear it mentioned that this was in the works?
Detecting/handling OS links at the resource or filesystem level isn't currently planned.
There's not much we can do at thbis time then.
(In reply to comment #4) > There's not much we can do at thbis time then. I think the "delete any CVS trees which aren't rooted at a project" behaviour is wrong especially as this behaviour is eager, silent, and destructive. In the general case it's very difficult / impossible for the user to recover from this as they need to know which CVS version each file in their project is based on... A far better solution would be to respond to after the fact resource delta notifications and prompt the user that copying / moving trees within the workspace will result in the destruction of CVS data -- if the user doesn't want their CVS data deleted, then prevent team operations on that tree...
I also think deleting CVS folder in subdirectories is really wrong. Linked folders is not just the only thing that suffer from this, nested projects as well (when a project is below another project in the directory structure). How about having these two cases, linked dir and overlapped projects, excluded from any CVS operations, including synchronization.
Regarding my previous post: when I talked about linked folders I meant symbolic links in linux. Now I realize this is about workspace linked folders. Nevertheless, my comment about nested projects remains. In fact I'd like this to be classified as a critical bug: Eclipse supports nested projects (projects sitting inside the directory hierarchy of another project). In no situation should the outer project delete CVS info of an inner project. Due to loss of information, it should be marked as critical. See also bug #41929
Sorry, I got confused coming from another bug: this bug is really about linked folders as in symbolic link in posix systems (ln -s). There's probably not much we can do about symbolic link in project folders since it's outside eclipse control and detecting them in java is not straightforward. However detecting nested projects is really within eclipse's ability and we should really prevent their CVS folder from being deleted. I'd say this even if the nested project is not in the workspace (.project file present?). With such behavior, one can easily overcome the original issue about symbolic links: make sure the link points to another project root. I'd like to encourage you to address this issue in a prompt manner. Thanks!
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.
