Community
Participate
Working Groups
In a project which is under control of CVS (this point is important) I select a folder (which content is in sync relatively to CVS and to the filesystem) and do copy. When I paste the folder onto my filesystem. I do get all the files that I was seing into the resource navigator, but I also get the CVS directories.... I don't really expect those last one to be copied.
Pascal, I presume that you mean you copied from the Navigator and pasted into a Windows Explorer window. Moving to Platform/UI for comment. How does the copy/paste (data transfer) onto the Desktop work? Does it create a visitor and copy that way or does it resolve to the location on disk and then copy the whole subtree?
Yes it is the case.
I assume you're in the Navigator view. Knut, can you comment in DJ's question?
The data transfer does not use resource visitors. It operates on the file system. We only place the name of the selected resource(s) in the clipboard, not the entire subtree.
I would say that this is expected behaviour and mark it as an enhancement request to not copy Team Private Members. Related to (but not a duplicate of) bug 24263.
The only way to fix this would be to use a resource visitor and place every single resource contained in the selected resource on the clipboard. For the Navigator drop operation we could use a resource visitor for the recursive copy. This is in CopyFilesAndFolderOperation which is API. Bug 24263 suggests adding new copy API. That would make the fix a lot simpler. Deferring
CCing KevinM since VCM should be involved in the decision about this behaviour.
Investigate for 2.2
Reassigning to Nick since he is taking ownership of Navigator
I suspect this is a bigger problem for Subversion than it is for CVS. Subversion stores a lot more information in its metadata so copying it can have very bad side-effects. I have entered bug 109166 to request a copy hook for team providers so that we can perform the copy. However, having Eclipse not copy the team private members would go a long way towards making the built-in Eclipse behavior safer.
Mihcael, any suggestions for how to handle this case?
I think that having a copy hook is the best solution as it frees others (e.g. navigator, JDT, etc) from needing to have custom logic that avoids copying the team-private members. I think it is unreasonable to ask every client that uses the IResource#copy methods to traverse the structure being copied to ensure that it doesn't contain team-private members. I would mark this a duplicate of bug 109166.
We might need to change the Navigator code anyway. We may be doing the work ourselves rather than just calling IResource.copy.
Yes, if you are doing the work yourself than you need to make sure that you skip team-private members. Also, if it turns out your are doing the work yourself, you must bare in mind that you could be defeating any potential gain that a repository gets from preserving copy semantics. This isn't a big deal for CVS since it is file based but more sophisticated repositories will preserve history accross copies and other neat things. You would want to make sure you don't defeat that by implementing your own file copy semantics (assuming that bug 109166 gets fixed).
Actually, the Navigator uses CopyFilesAndFoldersOperation, which uses IResource.copy, with special handling for copying into existing folders, handling linked files, etc. I believe it should be OK if bug 109166 gets fixed, but it needs to be tested. cc'ing Dirk so he can comment on JDT's copy operation(s).
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.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
