Community
Participate
Working Groups
I have two projects - the head and a branch - I wanted to port a directory with a set of files from the head to the branch. I selected the folder in the head and ctrl-c went to the spot in the branch and ctrl-v. This resulted in the files coming over - good - but the files are still part of the head - bad. The files should have been copied without their cvs info such that they would appear as new resources inside the branch and could then be committed to that branch.
The work around is to right click the added folder in the branch and select cvs then disconnect. You can then commit them to the branch. I think this is a pretty bad situation to have a mixed branch where you might not be aware that you are commiting changes to the head even though your project is a branch.
Unfortunately, this is a consequence of CVS. Try this with a sandbox created by the CVS command line client and you will get the same behavior. The best we could do is warn the user that they are mixing tags (as we do when they mix tags using Replace with). I don't think we'll have time to address this in 3.0.
*** This bug has been marked as a duplicate of 54006 ***
It is true that if you did this with the commandline client then indeed you would see the same behavior. I believe the difference here is that since the cvs folders are hidden from the user and you copy a folder from one branch to another you are less likely to realize that the cvs folders with cvs info will be copied and result in a mixed branch. Now I see that you have resolved this as a duplicate of an enhancement. I'd have to argue for this being a bug. When you want a mixed branch project? I don't think that is a state that should be possible to have. I think the proper behavior would be to have copy not copy the cvs meta data folders. I mean even if you were copying within the same project you wouldn't want the cvs folders copied since you are moving resources and would assumably like to move them in respect to the cvs project. If a warning is the best you could for 3.0 then so be it but
I agree that this is a separate case from bug 54006. However, a solution for that bug would aleviate the need to address this one to some extent. We will not have time to address this in 3.0. At the CVS level, it is difficult to differentiate the case where the CVS folders should be purged from the case were they shouldn't (i.e. even though you can't conceive of why a user wants a mixed project, CVS supports it and to not allow it in Eclipse is an unnecessary restriction).
I agree that you should allow the full flexibility of cvs through eclipse, however, in the future it would be nice to have an option to disable copying of cvs meta data with copy commands. Even if this were a disabled checkbox that I could enable it would improve my workflow and probably the majority of the other eclipse users when porting files from one branch to another. Another option would be to has the checkbox in the warning message itself. Now that I think about it a little more there is one case that I can envision the mixed branch being of value; that is if you were developing a project based on two different projects and wanted to use files from each inside the one project. Still a lot more of a fringe case than porting files from one branch to another.
*** Bug 171065 has been marked as a duplicate of this bug. ***
Can the Eclipse users get a patch to correct this bug? Simply copying a folder from one project with CVS folders to another project that is connected to CVS will alter version control information. This is unexpected; I expect this problem when done using a native OS copy command, but not when done through Eclipse. I think it is reasonable to expect that Eclipse, being aware of version control schemes, can exclude CVS/SVN/etc version information metadata folders where appropriate. Without this patch, it becomes the end user's responsibility to make sure that underlying version control system files are properly maintained. It is very easy to overlook that Eclipse does not do this automatically. Please consider creating a patch for this!
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.
