Bugzilla – Full Text Bug Listing
| Summary: | [CVS Core] Builder copying CVS folders is a problem | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
| Component: | Team | Assignee: | Platform-VCM-Inbox <platform-vcm-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.blewitt, ekuleshov, gabriele.garuglieri, gunnar, panagiotis.korros |
| Version: | 2.1 | ||
| Target Milestone: | 3.1 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 76664 | ||
| Bug Blocks: | |||
|
Description
Michael Valenta
We should consider this for 2.1.1 Just to add some justification, this can happen in a couple of situations. The first is if the CVS plugin is not loaded when a CVS project is imported. The second is if a builder is file-system based (and doesn't check team-private). If either of the above two cases occur and the build directory of the project is shared, the user will end up with outgoing deletions. Unfortunely, I forgot that the root of the problem is that there is no CVS code loaded when the problem occurs so it is the above mentioned solution is no good. All we can do for 2.1.1 is provide guidance on how to avoid the problem so it doesn't occur and how to recover from it if it does. *** Bug 56547 has been marked as a duplicate of this bug. *** Post 3.0 *** Bug 57400 has been marked as a duplicate of this bug. *** What about a CVS Builder Cleaner, that runs after the rest of the builders and prunes any directory called CVS from any output directory? That way, the problem isn't in the copying into, it's solved by a cleanup script. Would also solve the issue in bug 56547 whereby the CVS directories are copied into the build directory before the CVS plugin is loaded. Obviously the builder would be activated as part of the CVS plugin, so it shouldn't affect the presence of CVS directories when CVS is not in use. Regarding comment #6, the builder does scrub the CVS folders from the build directory. There are two problems though. One is that it is hard to differentiate valid CVS folders from an invalid ones in some cases (e.g. when the build output folder is also shared). This is rather infrequent so it's not that big a problem. The main problem is that the build clearer only runs after a build so the CVS folders will be there from the time the change was made until after the build finishes. Unfortunately, this gives plenty of opportunity for the CVS folders to be detected and interpreted by either the CVS plugin or some other plugin. The previously stated problem also still exists (i.e. the copy can take place without the CVS folder being loaded). The build cleaner will clean these once CVS is loaded and a build takes place but there is still plenty of opportunity for others to see the CVS folders. This things is starting to become an issue. I have verified this behaviour with 3.1M4. 1- start with a clean installation 2- import an existing project extracted from CVS. 3- the builder copies all the CVS directories in the source tree in the output directory 4- share the project From now on i'm no longer able to get rid of the CVS folders from the output dir. When i clean the project everything, but the first CVS folder coming from source directory, is wiped out from output dir and, even if i manually delete that CVS folder from output dir, when i rebuild all the CVS folders are again copied to the output dir. This happens only for the first imported project, any subsequent imported project is correctly cleaned up when is rebuilt after sharing. Due to this problem a contractor working for us, has managed to corrupt a project in the CVS repository. I request that the priority of this problem be raised due to the potentiality of CVS repository corruption. I discovered some more things. In my last update i assumed that the subsequent projects were succesfully cleaned up because i was not seeing the incoming delete caused by CVS folders in the output dir, but really the CVS folder ARE ALWAYS COPIED to the output dir for each project, independently of the fact that it is shared or not. I found that i need to stop/start eclipse, perform a full workspace clean/build and all the synchronize view is cleaned from those fake incomng delete, but the CVS folders are still phisically there. I hope this is not the intended behaviour. This problem is bothering me and my team also. We use subversion and the subclipse team provider plugin. The problem described above makes it very difficult for a developer to start working on a new workspace. If we checkout a set of projects from subversion in order to import them into a new workspace we have to: 1. start a new eclipse workspace 2. turn off autobuild 3. import all projects (be carefull not to expand the project nodes) 4. share the project using the subversion team provider 5. turn auto build on If we don't turn of the autobuild before the import or expand the projects after the import the .svn folders are picked up by the eclipse builders and copied into the output folders. I think that this is a major issue and that it should be addressed in the 3.1 timeframe (Theme: Simple to use) I cannot believe that! Something must have gone out to the blue between M3 and M4. Since 2.0 i've always been on the bleeding edge, but i'v never seen something like that, up to 3.1M3. After a while i'm working those incoming deletes resurface again. To be sure it's not some old plugin that screws up the things i set up a clean environment to reproduce the problem. I'm using an out of the box clean install, a fresh workspace where i imported three projects, and looking to the progress and the sync views, while doing cycles of clean/rebuild/synchronize is like looking to the lights of a Xmas tree, lot of sync task not terminating and those fake incoming deletes, flashing on and off in the three projects in a seemingly random fashion. I still do not understand how that contractor was able to corrupt the project in CVS, but i don't want to risk and i guess i'll have to revert back to M3 if i want to do some productive work. The long-term solution for this is to fix bug 76664. You may want to add yourselves to the CC list and vote for that bug. Another bug that you may be seeing is bug 76853. That would explain why the CVS folders are not being properly purged when the CVS plugin is finally loaded. I'm not sure why you would start seeing this only in 3.1 M4. I don't recall any code in this area being touched recently but I'll have a look. Hi Michael, i don't know either why now it's behaving this way. I verified in the meanwhile that indeed the CVS folders are not purged also in M3, but after sharing the project they are consistently ignored. I installed M3 the day after its release and i'm still working with it but i've never seen any problem with those copied folders. With M4 i imported the same projects (i keep them out of workspace), but since the beginning i've not been able to reliably work with it since those fake deletes resulting from interpreting the copied CVS folders keep appearing and disappering in a random fashion in the sync view. The only thing i've noticed looking in the progress view is that, when asking for a sync, sometimes the launched sync task are not terminating, at least they show this way in the view, and i start seeing those fake deletes. I will investigate what is happening during the share. I am also hoping to come up with a general solution. I will keep you posted. I have released a fix that is in today's integration build (I20040118). It will ensure that the CVS plugin is loaded when CVS metafiles are created so that they can be marked as team-private (i.e. hidden from the builders). It will also auto-share CVS projects. The facility that was introduced is also usable by other repository providers. A field has been added to the repository extension point for specifying the core metaFilePaths that are used by the repository client. If all the specified meta-files are present in a project or folder, the method RepositoryProviderType#metaFilesDetected method is invoked. This gives the repository provider an oportunity to mark them team-private. The CVS plugin also launches a bakground job to auto-share the project. See the extension point doc and javadoc for more details. *** Bug 76664 has been marked as a duplicate of this bug. *** Thanks Michael, i'll try the new build asap. I'm on a tight schedule right now. About the autosharing, it's just an opinion since i din't try it yet, but may be it's a bit overkill. I mean, if you implemented it the way that Bug 76664 was requesting, ie with a checkbox, so that the user can decide if autoshare or not, well so far so good. But if the user cannot choose if autoshare or not, i guess someone will complain about this. Just as an example consider that i usually keep shared large projects, like Tomcat, ant, Jboss, to use as code reference when something is not clear in the doc or is not working like expected. Now i'm wondering what could happen if i decide to pupulate a new workspace importing those projects... I have them on local filesystem, but the CVS repositories are remote and not that fast, so forecasting based on present behaviour, i guess i could end with an almost locked workbenck till the autoshare is finished. Instead i would prefer to be able to choose when sharing a project, immediate autoshare for internal projects from intranet fast repositories, delayed share for remote internet repositories. Besides, don't forget that Bug 76664 was also asking for a way to automatically add the project to a Working Set during import. Auto-sharing does not contact the server so there is no overhead associated with doing it. I couldn't think of any undesirable effects so I did not provide an option. If bad side effects do occur in some cases, then we will add an option to disable it. The second part of bug 76664 was covered by a separate bug. Can we open bug 76664 again? It's not a dup and this bug doesn't solve it completly. The ClearCase team provider need to check if the project folder is located inside a VOB. Thus, some kind of callback API would be necessary. You can reopen it if you like but realistically it will never be addressed. Given this bug has been fixed, the payback of bug 76664 is small and the fix is far from trivial. I know that the commercial ClearCase plugin already performs auto-sharing so there must be a way to do it with the current Eclipse architecture. I guess they are using a resource listener for this. Fix was released |