Bug 116140 - [IDE] RenameResourceAction should delete before rename
Summary: [IDE] RenameResourceAction should delete before rename
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on: 20036 31883
Blocks:
  Show dependency tree
 
Reported: 2005-11-13 11:59 EST by Gunnar Wagenknecht CLA
Modified: 2022-01-15 13:47 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gunnar Wagenknecht CLA 2005-11-13 11:59:59 EST
If I rename a file to a file that already exists the existing file is not
deleted before the rename. Instead, the content is replaced and the other file
is deleted.

I think this behavior is not what someone expects when doing this. Especially if
the files are versioned using an SCM I would expect to keep the history of the
original file and drop the one from the overwritten one. 

I would expect the following:
- delete the existing file
- rename the file

See the following thread from the newsgroup:

John Arthorne wrote:
> You receive this delta because this is exactly what the UI does in the 
> case of an overwriting rename.  The UI code of the rename action calls 
> setContents on the b.txt, and then deletes a.txt. Hence this is the 
> delta you receive.  In short, this means it is impossible to detect the 
> difference between a plain modification of b.txt, and the case were the 
> contents of b.txt are set to be the contents of a.txt.  Here is the 
> snippet of code from RenameResourceAction:
> 
> if (newResource != null) {
>   if (checkOverwrite(getShell(), newResource)) {
>     if (resource.getType() == IResource.FILE
>       && newResource.getType() == IResource.FILE) {
>       IFile file = (IFile) resource;
>       IFile newFile = (IFile) newResource;
>       if (validateEdit(file, newFile, getShell())) {
>         IProgressMonitor subMonitor = new SubProgressMonitor(
>           monitor, 50);
>         newFile.setContents(file.getContents(),
>          IResource.KEEP_HISTORY, subMonitor);
>         file.delete(IResource.KEEP_HISTORY, subMonitor);
> -- 
> 
> 
> Karen Harris wrote:
> 
>>
>> I'm having a problem detecting a particular change event. Say I have 
>> two files (let's call them a.txt and b.txt) in the same folder in my 
>> workspace. I then rename a.txt to b.txt. Eclipse pops up a dialog 
>> asking me if I want to overwrite the file and I reply yes. The 
>> resource change events I receive are a root content change, a project 
>> content change, some marker change events, and a file content change 
>> event. What I need is to detect a change that tells me both the prior 
>> name of the file and the new name of the file, which I am not 
>> receiving. Am I missing something? I don't have to use resource change 
>> events if there's some other way to detect that a file has been 
>> renamed to an existing filename.
>>
>> (Note that most other situations are working fine for me. If I rename 
>> a file to a unique name, I get the expected add/moved-from and 
>> delete/moved-to events. Also, if I copy a file a.txt to another folder 
>> where there's already a file called a.txt, I get the overwrite 
>> confirmation popup, but then I also get add/moved-to and 
>> removed/moved-from events, so I have all the info I need.)
>> Any help/insight into what's going on here would be deeply 
>> appreciated! BTW, I'm using Eclipse 3.1.0.
>>
>> Thanks!
>> Karen
>>
Comment 1 John Arthorne CLA 2005-11-14 14:39:53 EST
This merging on copy/move is actually intended behaviour that was done
specifically to support team repository providers.  If you delete the file and
then recreate via copy/move, then it will appear as a new file and be shown as
an outgoing creation.

See bug 31883 for a longer discussion (and request to push the merge on
copy/move behaviour down into the core implementation).
Comment 2 Michael Van Meekeren CLA 2005-11-14 15:02:19 EST

*** This bug has been marked as a duplicate of 31883 ***
Comment 3 Gunnar Wagenknecht CLA 2005-11-15 01:13:47 EST
I'm reopening this bug to have a discussion about this. My understanding is that
bug 31883 was only implemented to overcome some disabilities of CVS. We are
using ClearCase and Subversion and both are able to track renames and deletes.
If a file is renamed and overwrites an existing file than it's actually a new
element and not related to the existing file.

The reason I need the resouce delta to reflect the move is the following. We
track renames to also rename other resources related to this file. However, due
to the content replaced delta we arn't able to discover the rename.
Comment 4 Michael Valenta CLA 2005-11-15 08:34:59 EST
If you are tracking renames so that you can adjust other files as a result, 
this implies that there is some relationship between these files due to a 
higher level model. This is the problem that the Eclipse logical model support 
is trying to solve. You should have a look at bug 37723 and follow the links 
there to see what is planned for 3.2.

I think the issue remains that the behavior of RenameResourceAction is wrong. 
It should not treate the move as a merge. It has to be a move or repositories 
will lose file history. However, I think that the Core level is the proper 
place to implement the behavior by having an overwrite exisiting destination 
flag as indicated in bug 31883. It is probably worthwhile to keep both bugs 
open since the UI/IDE Team will need to make changes if and when the Core bug 
is fixed.
Comment 5 Susan McCourt CLA 2009-07-15 12:07:01 EDT
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
Comment 6 Eclipse Webmaster CLA 2019-09-06 16:15:31 EDT
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.
Comment 7 Eclipse Genie CLA 2022-01-15 13:47:23 EST
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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.

--
The automated Eclipse Genie.