Community
Participate
Working Groups
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 >>
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).
*** This bug has been marked as a duplicate of 31883 ***
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.
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.
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
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.
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.