Community
Participate
Working Groups
Team providers, at least Subversion, need to be able to capture the copy event just as much as they need to capture the move event. This is especially true for folders. Subversion stores metadata in a hidden folder. When you copy a folder, that metadata is copied with it. If the target of the copy is a Subversion working copy this leads to corruption. If the target is the general file system it leads to unwanted files. Ideally, we would like to capture the copy event, as we do the move event, so that we could run the Subversion copy or export process. This would allow the copy to be performed correctly.
*** Bug 24263 has been marked as a duplicate of this bug. ***
*** Bug 169592 has been marked as a duplicate of this bug. ***
Please see bug 217489 which has a patch to provide COPIED_FROM on the IResourceDelta. This might be helpful to either directly use, or as a basis for extending the Team notification hook.
I'm not sure if bug 217489 is necessary here. At least in case of Subversion it replaces the whole copy operation and does the copy on its own (like with move) to that the Resources API just need to send out the notifications.
Yep, this bug is about the ability to override/re-implement the copy behaviour. A post-change event isn't sufficient.
(In reply to comment #5) > Yep, this bug is about the ability to override/re-implement the copy behaviour. > A post-change event isn't sufficient. So this bug is really about the copy hook mechanism similar to the move/delete one, right?
hi folks, how about getting this and the related bugs finally done in 3.6?
Hi Thomas. Looking at comments 4, 5 and 6, it looks like this bug doesn't depend on bug 217489. We don't plan to address it during 3.6, however help and contributions are welcome. I will find time to review Francis' patch at bug 217489 but that's all I can promise right now.
*** Bug 318430 has been marked as a duplicate of this bug. ***
Are there any plans for this problem?
(In reply to comment #10) > Are there any plans for this problem? I will help with this enhancement, if someone from the community is planning to work on it. I guess that you or someone else started hacking the code. So please share your work and I'll comment on it.
Any news on this? It has been opened in 2005 (!!!) and it's still blocking bug #310278, a major Subversive bug that leads to corruption of local data. Why isn't this considered?
(In reply to comment #12) > Any news on this? It has been opened in 2005 (!!!) and it's still blocking bug > #310278, a major Subversive bug that leads to corruption of local data. Why > isn't this considered? See commet 11: "I will help with this enhancement, if someone from the community is planning to work on it. I guess that you or someone else started hacking the code. So please share your work and I'll comment on it."
(In reply to comment #13) > (In reply to comment #12) > > Any news on this? It has been opened in 2005 (!!!) and it's still blocking bug > > #310278, a major Subversive bug that leads to corruption of local data. Why > > isn't this considered? > > See comment 11: "I will help with this enhancement, if someone from the community > is planning to work on it. I guess that you or someone else started hacking the > code. So please share your work and I'll comment on it." Alexander, do you have any plans to supply a patch to the Eclipse core team? Your Polish neighbors are looking forward to review it... :-) Cheers, Jörg
(In reply to comment #13) > See commet 11: "I will help with this enhancement, if someone from the > community is planning to work on it. I guess that you or someone else started > hacking the code. So please share your work and I'll comment on it." Hi Szymon, I read your comment, however my question is then another: isn't there any plan by the Eclipse Platform team to address such important enhancement requests like this (with 16 votes, lots of CCs, important blocked bugs, opened since 2005, etc.) if no one from the community is able to step in and help? I know it could sound false, but I would certainly happily help if I could, however I don't know anything about the development of Eclipse and I'm a phase of my life in which I don't have enough time to spend on this, unfortunately.
(In reply to comment #14) > Alexander, do you have any plans to supply a patch to the Eclipse core team? > Your Polish neighbors are looking forward to review it... :-) > > Cheers, Jörg Yes, indeed, this is in my plans for quite some time, but I still have my hands full with many other tasks and because there is a way to avoid the situation using "Team->Copy To..." action the problem itself is not a blocker. That is why I will take on this task as soon as I've finished with other important matters.
Hey guys, Any news? This is a really serious bug. It's been ages since this bug has been assigned and six months have passed since Comment 16. Moreover, if you want to copy a gwt module you have no workaround at all. It always ends up with a partial copy (comprising wrong .svn metadata) and a failure, both using copy/paste and using Team|Copy to (the latter would be insufficient in any case, as it does not rename the java file contents to reflect the new packaging)
(In reply to comment #17) Unfortunately there is no progress from my side with creating a patch, I have my hands full all the time and I've no estimate for when I could do it in the future too.
(In reply to comment #18) > (In reply to comment #17) > Unfortunately there is no progress from my side with creating a patch, I have > my hands full all the time and I've no estimate for when I could do it in the > future too. Platform Workspace team does not plan to work on this for the Juno release. If you really need it, please provide a high quality patch with tests.
with the new WC metadata format (just one .svn @ the root of the WC) i find that this is much less of a problem now. so, maybe just upgrading to SVN 1.7 will do the trick.
(In reply to comment #20) > with the new WC metadata format (just one .svn @ the root of the WC) i find > that this is much less of a problem now. > > so, maybe just upgrading to SVN 1.7 will do the trick. PS: i use tigris' subversive though
(In reply to comment #21) Thank you for your comment it seems SVN 1.7 working copy format is really useful to solve the issue too. P.S. Subversive does not support SVN 1.7 yet (it is in development right now).
I know the SVN 1.7 API solves the problem, but the problem still exists. First of all, Subversive, the "official" Eclipse plugin for Subversion access (and part of the Indigo release train) is not yet compatible with the SVN 1.7 API. Secondly, this bug is about a problem (the lack of a hook for the copy event) which is not strictly speaking just a Subversion integration problem. And lastly, yes, there are still a lot of users of Subversion pre-1.7 clients. If you look at the bugs this is blocking, there's also bug #33924 (reported in 2003). That also references bug #217489, which has had a patch since February 2008, never checked in. May that patch be enough for the blocked bugs to be fixed?
It is possible with the current EFS support in the Eclipse Platform for a repository provider to track copy events by wrapping projects shared with their repository with their own EFS. This is what RTC/Jazz SCM does. There are some complications due to minor bugs in the Platform or in clients that reference project resources improperly through the EFS but it works well for the most part. I'm not sure if there is any benefit in providing addition support through deltas or the move/delete hook. A better approach may be to have the SVN providers adopt this approach and deal with any bugs encountered. P.S. Many of the bugs we encountered in Eclipse have already been fixed in Eclipse but RTC ships on an older version of Eclipse.
