Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 323628 - Files lost from CVS when replacing with nonexistent version
Summary: Files lost from CVS when replacing with nonexistent version
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: 3.7 M2   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-25 11:42 EDT by Markus Keller CLA
Modified: 2010-09-14 15:56 EDT (History)
3 users (show)

See Also:

Attachments
Proposed Fix (2.37 KB, patch)
2010-08-25 11:44 EDT, Markus Keller CLA 		no flags Details | Diff
Fix (6.29 KB, patch)
2010-09-02 02:33 EDT, Dani Megert CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2010-08-25 11:42:18 EDT 
3.6

Files lost from CVS in the workspace when replacing a project with a nonexistent version and the project had outgoing changes.

- check out tag R3_6 of
  - org.eclipse.ui.editors and
  - org.eclipse.jdt.junit.runtime
from :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse

- on org.eclipse.jdt.junit.runtime, open "Properties > Java Compiler > Building > Build path problems", and set the last option to Warning (confirm rebuild)

=> 2 files in org.eclipse.jdt.junit.runtime/.settings have outgoing changes (good)

- select both projects
- context menu > Replace With > Another Branch or Version...
- confirm "Overwrite Uncommitted Changes"
- replace with branch "R3_6_maintenance" (which is not available for org.eclipse.jdt.junit.runtime)

=> No changes visible in the workspace any more. But when you synchronize the whole workspace, you get incoming additions for the 2 prefs files.

This bug hit me in a maintenance build input where I accidentally released org.eclipse.jdt.junit.runtime with a new tag, although the plug-in has not been branched at all (but the Release... wizard detected the project as changed).
Comment 1 Markus Keller CLA 2010-08-25 11:44:21 EDT 
Created attachment 177433 [details]
Proposed Fix

This patch modifies the ReplaceOperation so that it doesn't delete files from projects that won't be replaced in the end because the tag doesn't exist.
Comment 2 Dani Megert CLA 2010-08-26 10:09:53 EDT 
Thanks for the patch Markus. It looks correct.
Committed to HEAD.
Available in builds >= N20100826-2000.
Comment 3 Dani Megert CLA 2010-09-01 05:08:33 EDT 
Argh! That patch is no good: it breaks 'Override and Update'.
Comment 4 Dani Megert CLA 2010-09-01 05:52:51 EDT 
Reverted the fix in HEAD. Since the ReplaceOperation is used in multiple paths it's probably best (and most performant) to fix it in ReplaceWithSelectableTagAction or its super class by excluding the resources which don't have the selected tag.
Comment 5 Dani Megert CLA 2010-09-01 06:13:22 EDT 
> it's probably best (and most performant) to fix it in
> ReplaceWithSelectableTagAction or its super class by excluding the resources
> which don't have the selected tag.
This would also allow us to defer the warning that files will be overwritten to the point where we know which projects get replaced.

I'll try to take a look during 3.7 but not now.
Comment 6 Dani Megert CLA 2010-09-02 02:32:41 EDT 
>This would also allow us to defer the warning that files will be overwritten to
>the point where we know which projects get replaced.
I've not done that as this would mean bigger changes.
Comment 7 Dani Megert CLA 2010-09-02 02:33:31 EDT 
Created attachment 178017 [details]
Fix
Comment 8 Markus Keller CLA 2010-09-14 15:33:34 EDT 
Verified original scenario and comment 3 in I20100914-0100.
Comment 9 Deepak Azad CLA 2010-09-14 15:56:27 EDT 
Verified for 3.7M2 on Linux with I20100914-0100.