Bugzilla – Full Text Bug Listing
| Summary: | [Operations] Eclipse erases project files when doing a CVS replace | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Max Gilead <max.gilead> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | remy.suen |
| Version: | 3.2 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Max Gilead
There is an option to make Eclipse delete unmanaged files on replace (Team>CVS>Files And Folders>Delete unmanaged files on replace). You can turn it off and these files shouldn't be replaced. We've modifed how replace with HEAD works in 3.2 so we'll need to ensure that it honors this setting. We should also consider special handling for . files and directories that appear at the root of a project (.project, .classpath, .settings) but I'm not sure what we'll have time for in 3.2. I'd expect that CVS replace removes files which are not in the repository (after all it's a replace, not update) but Eclipse project files IMHO should be treated differently. If they're removed by CVS replace this option becomes pretty much useless -- user won't be able to do a CVS replace at all without destroying a project. I know that Eclipse is a very configurable environment but I doubt anyone would want project files removed by such operation. If you choose to provide such option anyway please make if safe by default so that project files aren't removed. I agree that the .project file should always be left untouched. I think the replace bevahior should be: 1) never removed an unmanaged .project 2) have an option for other unmanaged . files and folders (we'll call them configuration files) 3) have an option for other unmanaged files and folders. However, it becomes tricky because if we leave the files and someone else has checked it in, the "cvs update" will fail. This means that, to make this work, we need to change the way the replace works. As I said, we'll have a look at what we can do for 3.2, but it is a bit late in the cycle to be considering chaning how the repalce works. As an aside, doesn't the .project and .classpath get recreated with the proper contents? They have in the past when we've hit this problem. Is this no longer the case? IMHO when configuration files exist in the repository local files should be replaced with remote copies when doing a replace. I don't know if . files are recreated -- I restored mine from local history. I think that to to resolve most important problem (data loss) code changes can be minimal -- just don't remove unmanaged configuration files when doing a CVS replace. There are a couple of things to consider here: 1) Removing the .project and .classpath files does not result in dataloss because the files are just recreated with the same content (although, as you noticed, an error is thrown as well). 2) I don't believe a "cvs update" (which is the command we use for replace) will replace an unmanaged local file with a remote file so we would need to write a custom command to perform the replace with the semantics you are requesting 3) There is an option to specify that unmanaged files should not be removed. 4) As you say, you can restore the content from local history as well. 5) We are in the lockdown phase of 3.2 6) The replace semantics have not changed since 2.0 These are all the factors we need to consider when determining what can be done for 3.2. I believe we will be able to get the proper sematics in place for Repalce with Latest with HEAD since we already have a custom operation for that but we will probably not be able to change the way "Replace with Branch or Version" works for 3.2. I was wrong about Replace with latest from HEAD. We had switched to doing a model update but then we switched back. This means that the semanitics for this are the same as they were in previous releases. Addressing this bug will be too much of a change for this late in the cycle. Deferring to 3.3. Unfortunately, we will not have the cycles to address this issue in 3.3. *** This bug has been marked as a duplicate of bug 108047 *** |