Bugzilla – Full Text Bug Listing
| Summary: | [Sync Info] navigator crash CVS dir on directory symbolic links | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Everton L. Berz <everton> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | Alfredo.Bencomo, eclipse.org, esse_, gunnar, jbadenhop, Michael.Valenta, neal.gokli+nospam, tom.dalton |
| Version: | 3.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 44107 | ||
| Bug Blocks: | |||
|
Description
Everton L. Berz
Incomplete bug report. Please provide steps contents of .log file, vm version. Sorry if my report was incomplete. I don't know what you saw with ".log, vm version", it's necessary? I'm just reporting the wrong behavior that Eclipse Navigator (on CVS mode) have. I will try explain: 1. There is a project with symbolic links for a directory: ./project/ | ./project/index.html | ./project/CHANGELOG | ./project/CVS | directory contains CVS internal files ./project/themes/ | ./project/themes/default/ | ./project/themes/default/style.css | ./project/themes/default/CVS | directory contains CVS internal files ./project/themes/desert | symlink to folder ./default ./project/themes/ocean | symlink to folder ./default 2. When I run Eclipse and it see symbolic links, it thinks that must rebuild CVS structure of ./project/themes/default/CVS, because symbolic links was created and calling directory 'default'. It's causing a trouble on CVS directory and show files with Conflict flag. The problem is that the symbolic links you are creating contain a CVS folder. The CVS plugin always removes CVS folders from folders that are not managed by their parent. Since, the "desert" and "ocean" directories contain the CVS folder from the "default" folder, the CVS plugin will purge these folders (since desert and ocean are not managed), resulting in the conflicts you describe Perhaps you should create the desert and ocean as directories and add symbolic links for the files you need within these directories. Another alternative is to use Eclipse links instead of OS links. The CVS plugin is aware of Eclipse links and does not purge the CVS folders contained in them. However, the CVS plugin is not aware of OS symbolci links. Is it possible to re-examine this bug? My company makes frequent use of symbolic links inside its code tree. Usually to have a human readable name and a database id (usually a number) name for the same directory. This causes all sorts of grief when trying to use the Team Sync feature. The symbolic link shows up as a folder in the navigator with all the contents of the linked to folder - which is far enough and I can handle that. However, when I try to sync, both the symbolic link and the linked to folder (and all it's contents) show up with the status of 'conflicting addition' regardless of whether the local file has changed or not. Once the file gets that status, it never goes away - even if the symbolic link is removed. One way I've been able to restore sanity is to remove all the symbolic links, remove the local files and then update from CVS - not ideal if changes have been made to the local files. The command line version of cvs copes quite well with all this by simply not following symbolic links. Is it possible for the Eclipse CVS component to also not following symbolic links when determining difference between remote and local? Maybe as an option at least? Reopening This would only be possible if we could distinguish symbolic links from regular folders. Moving to Core/Resources. Is there any plan to make this information available? There is a request for symbolic link support in bug 44107. It's a reasonable request, but there are no current plans to work on this. I'll mark this particular bug as dependent on the resources enhancement request. I'm not sure if this is still a relevant discussion (I stumbled upon it while wrestling with the CVS plugin). Anyway... (In reply to comment #4) > The command line version of cvs copes quite well with all this by simply not > following symbolic links. I don't think this is the case (though may have misunderstood the discussion). The command line version of CVS treats symbolic links to directories the same way treats any other sub-directories. "Real" CVS doesn't need to know which directories are symbolic links, so neither should the CVS plugin. CVS uses the CVS/Entries file, which lists all the files and directories that are part of the repository. CVS doesn't put symbolic links there, unless you cvs add them manually. But even then, CVS doesn't support checking symbolic links into the repository (adding or importing them will result in a non-symbolic sub-directory in your repository). And if you manually create a symbolic link in your CVS repository, you will get an "actual" sub-directory in your working directory when you check out or update. Symbolic links can be useful. Depending on what you want, you can create them (manually or programmatically) in your local working directory, or you can create them in the CVS repository (avoiding loops!). But they don't stay symbolic when they cross the line from (to) the repository to (from) the working directory. Also, removing CVS/ directories because the Eclipse plugin thinks the directory isn't from a CVS repository sounds dangerous to me. "Real" CVS looks at CVS/ to decide if a directory is part of the repository. The plugin should act the same. Again, I'm not sure if this is still an issue (haven't had a chance to try it out), but I thought I'd follow up, since the bug is still not closed. I just lost some work because the CVS plugin deleted CVS directories in a symlinked directory. I'm lucky I was working off the latest HEAD branch... I thought I'd avoided trouble by not having the CVS perspective open. I've been using CVS from the command-line for the past month with no issues. But I closed Eclipse this morning, and it deleted some CVS directories. This time it's only "very frustrating" for me, but it could be Very Bad Thing. Dangerous, in any case. Is there a reason the CVS plugin even looks at directories it doesn't think are part of the repository? I've had good luck with command-line CVS, so I'll probably stick with that for now. Maybe I'll try to patch this plugin one day, but I don't have the time or the knowledge (about Eclipse) right now. I'd like to react to CVS folder deletion as well. It's too destructive and I would like to encourage something else than deleting the CVS dir. At least something must be done to better handle the situation I explain below. I was hoping symbolic links would be useful in the situation where a main project and its modules are in separate CVS repositories. Modules need to be placed in some subdirectory within the main project directory structure. So in Eclipse I created one project for the core and another project for the module. I symlinked the module inside the core project, but then noticed the module was no longer shared with CVS. Indeed, the CVS directory was gone. So it seems the only way to circumvent this issue is to use another tool outside eclipse to manage the outer project with CVS. Why do we need to have 1 project <-> 1 repository ? Overall this reflects again the lack of support for nested projects (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973), a real PITA in Eclipse. This problem makes it impossible to use Eclipse's CVS functionality in my work environment: We have 2 repositories, one containing shared code that is used by the other. I have to create 2 projects in Eclipse (because Eclipse does not support using 2 CVS repos in one project). I have to symlink the shared code directory from one repo (repo1/shared) into a directory in the other repo/project (repo2/code), so that repo2/code/shared points at the shared directory in repo 1. As soon as I update repo2, Eclispe deleted the CVS info from repo1/shared. This behavious is unbelievably poor. Even if I add repo2/code/shared to the .cvsignore file, this behaviour still occurs. Please can [we have an option] this behaviour be fixed as it's incredibly destructive (and has repeatedly resulted in data loss while I have been battling this issue). Additionally, the suggestion to work around the problem by using eclipse links instead of OS symlinks does not work as Eclipse links can only be make to files, not directories. 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. |