Community
Participate
Working Groups
If I open several projects in quick succession, sometimes a project will loose its association with its repository. This has been an issue for a while now but I just decided to report it. I opened 5 projects but clicking on them one at a time. While the first was still opening i proceeded to open the other 4. The 2nd project lost its association with its repository. I clicked Team and was able to easily reassociate it. I have seen this and other labelling issues when you try to open projects in quick succession. I believe the projects are compiling while I am opening them.
I am not able to reproduce this. Given that the consequences are not that bad, I am deferring to post-3.2.
You should try using a slower hard drive. A flash drive, or a network drive or something. So that it takes long enough to open the first project for you to be able to open the 2nd project before the first has really started. Its been doing this to me for a long time now, I have just started to open them one at a time. I have been doing that for over a year now.
Created attachment 47137 [details] Log File of the issue This occured when I selected and opened several Plugin Projects simultaneously in the Projects view. Most of them opened fine, but a few of them lost their association with the repository. Also, when I took the project home, the project still had lost its association. So whatever was lost must be part of the project itself. However, the CVS info is still there and the project is easily reattached. All projects are using the same repository in Eclipse.
I'm using 3.1.2 at this point. Issue still here.
On the other hand it occurs to me that the association could have been lost on project close. I'll have to keep a running log going on both computers. Next time I see the issue I will check if anything special happened on the last closing of the projects.
Some info on my setup. I have two computers, a desktop and a laptop. Both use workspaces located on their local harddrives. However, the projects in question are all on folders located on a flash drive. So I take the projects from desktop to laptop by moving the flash drive. The projects use linked output folders, but all other project resources are not linked.
I routinely open several at a time. I don't have this problem anymore. I suspect what happened is occasionally I open eclipse by mistake, without the drive being plugged in. Then Eclipse tries to open a project but fails. Then later when I open the project, its rebuilt but without the CVS info. Either way, I am closing this one since I open several at a time now, but dont see this error in 3.2.1.
I'd like to ask if you took a look at the log file and can tell me what it represents? It does still happen occasionally and I wonder if you can tell if the info is lost on workspace close, or open by looking in the log file? Im using 3.2.1 now.
The first exception indicates a failure to find the CVS metadata for the project. When that occurs, we unmap the project. If the hard drive wasn't accessible, then this could definitely happen. I could also happen during an Open if the project was being decorated before all the child folders were discovered by the open operation. We have already released a fix for the later case (i.e. in 3.2.x we check the disk directly for the CVS folder) but there's nothing we can really do in the former case.
When you say 'we' I assume you mean CVS or Team unmaps the project? If by chance my workspace is located on my harddrive, but my actual project folder is located at some removeable place, and that place is gone, then in this case, when you open the project, nothing is there, but the only thing that is changed and 'stored' is the removal of CVS data. Is there some way to recognize the whole project is missing and not write this change of CVS association to the workspace project? For instance, if several files are missing, they do not get removed permanently from the project. Next refresh they will show up. Perhaps CVS can get refreshed as well? If maybe we keep some note in the project that there is CVS association? Adding it back is really simple because the info is still actually there so to speak. just tossing around ideas for gentler error handling if at all possible.
What you suggest is probably possible. However, given the fact that you use case is extremely rare, we can;t justify assigning any resources to this problem at this time. However, we are happy to accept a patch.
Okeydokey. My strategy will be to open a dialog and ask the user if CVS data should be unmapped as a result of this error. With perhaps a checkbox to clear CVS data automatically in the future. That seems the fastest way to achieve this. Is this within Eclipse GUI guidelines?
We don't have access to the UI at the point where the unmap occurs. I think it is safe to say that, if the project directory itself doesn't exist, we can just leave it as is since any operations would fail (i.e. we unmap projects with no CVS meta-data to avoid CVS operation failures on projects that exist but are not really mapped to CVS. Since, in your case, the project directory doesn't exist, failures are unavoidable anyway).
OK. Well in this case all I need to do is check that the project directory exists, and if it does not, skip the unmapping of the CVS data. Can you point me to the code that performs the unmapping. Is the stack trace a good place to begin?
I did a search for all the senders of the RepositoryProvider#unmap method and it would appear that the most likely candidate for the unmap you are seeing is in CVSTeamProvider#getRemoteLocation().
I'm back on this one, sortof. It still happening in 3.2.2 so I updated the version. Probably won't get to it until school is out. Lowered severity to minor as its just an annoyance; no information is lost.
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.
