Community
Participate
Working Groups
Using Eclipse SDK: I20100420-0800 Subversive 0.7.8.I20100419-1900 SVN Connector 2.2.1.I20091215-1700 SVN 1.6 SVN Kit 2.2.1.I20091215-1700 I performed the following steps: 1. Copy folder "source" (with subfolders) within a subversive-enabled project 2. Paste the folder as "destination" into the same project (under the same parent directory) 3. Edit files below "destination" 4. Commit all changes Result: - Files below "source" have the changes I made in step 3. - Folder structure "destination" is marked as obstructed and not committed. In fact it is not possible to commit this folder using subversive. This is not only very broken behavior but makes it difficult to put the project back into a sane state.
As Eclipse doesn't have any hook for copy operation (although it has hooks for move and delete) Subversive can't intervene in copy operation and make needed changes, as a result SVN meta-information is simply copied which is wrong. Specially for this case there was added Team/Copy To action. Close as WONTFIX as we can't do here anything.
(In reply to comment #1) > As Eclipse doesn't have any hook for copy operation (although it has hooks for > move and delete) Subversive can't intervene in copy operation and make needed > changes, as a result SVN meta-information is simply copied which is wrong. So we agree that this behavior should never happen. > Specially for this case there was added Team/Copy To action. Which IMO is too deeply hidden to substitute the regular copy/paste actions. > Close as WONTFIX as we can't do here anything. The first thing you *can* do: talk to the people who implemented the CVS team support: in a similar setting no CVS directories will be copied. And if they use something which you can't use *please* negotiate with the platform people so that the same behavior can be implemented for SVN, too. Nobody will expect the same level of smartness in a copy/paste action as you can provide in specific team actions, but it should never screw up your workspace as badly as the scenario in this bug actually does. I'll leave it for you to re-open this bug.
Igor, I fully agree with Stephan: Since Subversion is different from CVS it is clear that there are Team API changes required to integrate Subversion as good as CVS is already integrated. Since CVS does not supported tracking of rename or copy actions, of course the API lacks support here. Therefore, I kindly ask you to request an API change in the early Eclipse 3.7 stage in order to be planned in. Finally, we could get rid of the extra Team/Copy To action and implement it by standard Eclipse API. Tomasz, please could you comment on the process how to request Team or Platform API changes? Thanks, Jörg
(In reply to comment #3) > Tomasz, please could you comment on the process how to request Team or Platform > API changes? Well this is quite simple: 1) file a new bug requesting the new API 2) describe your case 3) explain why do you think this should be API 4) read http://wiki.eclipse.org/Evolving_Java-based_APIs 5) provide a patch (if you have one) 6) prepare for discussion :)
I created a request to add hook for copy operation, see bug 318430. At least Subversive shouldn't corrupt working copy after copy operation: we can handle it as CVS which has resources listener which deletes meta folders, e.g. see org.eclipse.team.internal.ccvs.core.util.BuildCleanupListener.
(In reply to comment #5) > I created a request to add hook for copy operation, see bug 318430. > At least Subversive shouldn't corrupt working copy after copy operation: we can > handle it as CVS which has resources listener which deletes meta folders, e.g. > see org.eclipse.team.internal.ccvs.core.util.BuildCleanupListener. All this is good news! Thanks, Igor.
Isn't there the possibility to vote for bugs in the Subversive component? This is a very serious issue IMHO and should be fixed as soon as possible. The CVS client has no problems for this use case.
(In reply to comment #7) > Isn't there the possibility to vote for bugs in the Subversive component? I'm surprised, too, that voting is not possible here. So lets just use comments to indicate the importance of this bug. Igor, any news from you guys?
This bug once again (almost :) ) broke my neck. This time I had no intention of performing an SVN copy; simply copy&paste a directory (creating a new test case from an existing one). In this scenario knowing about "Team > Copy To" doesn't help. I would have needed a clean copy WITHOUT copying .svn nor performing any svn command. Quite a hassle having to export all new stuff into an archive file, revert-cleanup-revert-revert until the project is in a sane state again, and only then re-import the new stuff from the archive. Pretty please, provide a dialog with options to: (a) perform svn copy (b) copy files only (filtering .svn)
(In reply to comment #9) > In this scenario knowing about "Team > Copy To" doesn't help. > I would have needed a clean copy WITHOUT copying .svn nor performing > any svn command. > .... > Pretty please, provide a dialog with options to: > (a) perform svn copy > (b) copy files only (filtering .svn) In order to make a "clean" copy you can clear check box "Keep history" in the copying dialog after calling "Team > Copy To" action. Is this the option you needed or I misunderstood something?
(In reply to comment #10) > (In reply to comment #9) > > In this scenario knowing about "Team > Copy To" doesn't help. > > I would have needed a clean copy WITHOUT copying .svn nor performing > > any svn command. > > .... > > Pretty please, provide a dialog with options to: > > (a) perform svn copy > > (b) copy files only (filtering .svn) > > In order to make a "clean" copy you can clear check box "Keep history" in the > copying dialog after calling "Team > Copy To" action. Is this the option you > needed or I misunderstood something? Indeed I didn't see that check box. BTW on my system it is called "Keep resource history", which could easily be mistaken as referring to Eclipse's local history. So, apparently the required functionality is all there, and this bug concerns the usability, only: unambiguous wording and better integration with standard cut/copy/paste. Too bad we just missed another annual deadline for the related API request!
(In reply to comment #11) > Indeed I didn't see that check box. BTW on my system it is called > "Keep resource history", which could easily be mistaken as referring to > Eclipse's local history. Is something like "Keep SVN history" or "Keep SVN resource history" will be better?
(In reply to comment #12) > (In reply to comment #11) > > Indeed I didn't see that check box. BTW on my system it is called > > "Keep resource history", which could easily be mistaken as referring to > > Eclipse's local history. > Is something like "Keep SVN history" or "Keep SVN resource history" will be > better? I would say so, yes.
(In reply to comment #12) > (In reply to comment #11) > > Indeed I didn't see that check box. BTW on my system it is called > > "Keep resource history", which could easily be mistaken as referring to > > Eclipse's local history. > Is something like "Keep SVN history" or "Keep SVN resource history" will be > better? Alternatively, radio buttons could be used to select from ( ) Perform SVN copy ( ) Copy resources without SVN history
(In reply to comment #14) > Alternatively, radio buttons could be used to select from > ( ) Perform SVN copy > ( ) Copy resources without SVN history Thank you for your opinion, I've filled new report to address this issue: bug #341723.
I'm still wondering how the CVS plugin solves this problem. Even in CVS there are the CVS subfolders with metadata in them, but when you do copy & paste a folder under version control, these subfolders are not copied (or, at least, they are deleted after the pasting operation has finished). Why can't Subversive do the same with .svn folders? This bug is very important, it's surprising that it hasn't been fixed yet. It makes the whole Eclipse support for Subversion repositories unreliable.
(In reply to comment #16) Subversion meta-data are way more flexible than the CVS ones, so it is actually could be a little troublesome to detect if the meta-data are the wrong ones or not and if they were copied inaccurately from some other place or just were damaged in their rightful place. And so, the best way to handle the issue is to have the appropriate modification hook API.
(In reply to comment #17) > (In reply to comment #16) > Subversion meta-data are way more flexible than the CVS ones, so it is actually > could be a little troublesome to detect if the meta-data are the wrong ones or > not and if they were copied inaccurately from some other place or just were > damaged in their rightful place. And so, the best way to handle the issue is to > have the appropriate modification hook API. Alexander, please check bug 109166 comment 11. Thanks, Jörg
(In reply to comment #17) > damaged in their rightful place. And so, the best way to handle the issue is to > have the appropriate modification hook API. Yes, this would be the best, however the situation now is that you corrupt your working copy when you copy and paste directories and this is unacceptable, so I think that a temporary suboptimal solution should be put in while the API is not ready. In fact, I think that if one wants to do a "remote copy" (so a copy that keeps history), he can use the Team => Copy To. But when you do copy & paste you usually need just to do dump copies of your files or folders. That is, something you would do by creating totally new folders and files with the same contents of the source ones. In this case I don't expect Subversive to copy any metadata at all! So, if you have the following source: - src - .svn - myfolder - .svn - fileA - fileB and I copy and paste myfolder as mynewfolder, I expect to have something like: - src - .svn - myfolder - .svn - fileA - fileB - mynewfolder - fileA - fileB so, no .svn for mynewfolder, which should then seen as a brand new unversioned folder under src. In this scenario I don't see any difference with CVS. If I had created mynewfolder "manually" (using Windows Explorer, for instance) with some files inside it, the whole structure could be perfectly handled by a Subversion client (an Subversive too) as a new folder with new files inside them that are not present in the repository, so a commit would add them. Is there something wrong in my thoughts?
(In reply to comment #19) > so, no .svn for mynewfolder, which should then seen as a brand new unversioned > folder under src. In this scenario I don't see any difference with CVS. If I > had created mynewfolder "manually" (using Windows Explorer, for instance) with > some files inside it, the whole structure could be perfectly handled by a > Subversion client (an Subversive too) as a new folder with new files inside > them that are not present in the repository, so a commit would add them. > > Is there something wrong in my thoughts? There is this one little moment that ruins everything - actually we have no way to distinguish between copied resources and resources which were added to the workspace by refreshing the project, for example. That means we should do some assumptions about the whole matter and those assumptions may be wrong in the end.
(In reply to comment #20) > There is this one little moment that ruins everything - actually we have no way > to distinguish between copied resources and resources which were added to the > workspace by refreshing the project, for example. That means we should do some > assumptions about the whole matter and those assumptions may be wrong in the > end. And is this what the CVS plugin does? Does it make risky assumptions on the new resources? Otherwise, couldn't the Subversive plugin replace the standard "Paste" command with a custom command (instead of extending the standard one) for projects connected to SVN?
(In reply to comment #21) > And is this what the CVS plugin does? Does it make risky assumptions on the new > resources? > > Otherwise, couldn't the Subversive plugin replace the standard "Paste" command > with a custom command (instead of extending the standard one) for projects > connected to SVN? I've mentioned earlier, in case of CVS integration everything is much simpler, so there is no risks. And about "replace standard 'Paste'" - do you have an idea how to do it? I'm not. Instead there is the action "Team->Copy To" which is the real replacement for now.
(In reply to comment #22) > I've mentioned earlier, in case of CVS integration everything is much simpler, > so there is no risks. And about "replace standard 'Paste'" - do you have an I still can't understand the difference between CVS and SVN regarding this specific problem (new resources with CVS metadata coming from a project refresh may be wrongly interpreted as the result of a paste operation as well, if I follow your thoughts), however, don't worry, it doesn't matter. > idea how to do it? I'm not. Instead there is the action "Team->Copy To" which > is the real replacement for now. No, I don't, because I don't know the Eclipse API. It was just an idea.
Anyway, just to conclude. The use of Team => Copy To could be a reasonable workaround if you either: - disable standard copy & paste OR - alert the user as much as possible (documentation, website, popup alerts, etc.) about that he/she must not use copy & paste for folders when using Subversive to avoid working copy corruption I don't think there are many users out there that know about this issue, this bug and the workaround. Copy & Paste is just a so common operation that we can't hope that people just don't use it with Subversive (or know by themselves that they shouldn't do...).
I agree with you and, of course, I didn't mean that the problems should not be solved. It's just that this is not the only problem and there are still more problems of different importance that could and should be solved too. So, we will try to speed up solving of the existing issues to the best of our abilities, but solving this one still will take its place a bit later, because we think the best course of actions is to create the patch to improve Eclipse IDE API in this part.
*** Bug 411656 has been marked as a duplicate of this bug. ***
Just use SVN 1.7/SVN 1.8 connectors since they're not using .svn meta in each folder anymore. So, there won't be a corruption even if you're using copy&paste in order to copy resources. Actually, now it works just like in case of CVS.
