Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323628

Summary:

Files lost from CVS when replacing with nonexistent version

Product:

[Eclipse Project] Platform

Reporter:

Markus Keller <markus.kell.r>

Component:

CVS

Assignee:

Dani Megert <daniel_megert>

Status:

VERIFIED FIXED

QA Contact:

Severity:

major

Priority:

CC:

daniel_megert, deepakazad, raksha.vasisht

Version:

3.6

Target Milestone:

3.7 M2

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Proposed Fix	none
Fix	none

Description Markus Keller

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

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

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

2010-09-01 05:08:33 EDT

Argh! That patch is no good: it breaks 'Override and Update'.

Comment 4 Dani Megert

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

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

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

2010-09-02 02:33:31 EDT

Created attachment 178017 [details]
Fix

Comment 8 Markus Keller

2010-09-14 15:33:34 EDT

Verified original scenario and comment 3 in I20100914-0100.

Comment 9 Deepak Azad

2010-09-14 15:56:27 EDT

Verified for 3.7M2 on Linux with I20100914-0100.