Community
Participate
Working Groups
I have 3 branches, A, B, and C. I have merged changes from branch B into my workspace that is on branch A. I then created branch C off of A and did Team->Switch to Another Branch or Version in my workspace so that I could check the merge into C. After the commit, I found that all new and deleted files from the merge appeared on branch A, while the changed files correctly appeared on C.
*** Bug 80514 has been marked as a duplicate of this bug. ***
When will this get fixed? It has been open for years!!!
The severity of this bug should be incremented, because it's very easy to corrupt branches and then it's hard to rollback. Suppose you're working on branch A and you do some work (change some files, remove some others), then you realize that those changes don't have to be committed on branch A, but rather on branch B. So, you issue a "Switch to branch" and select B. Now, if you commit your changes, this is the result: - changed files are committed to B - deleted files are committed to A!!! So, not only you don't commit removals to B, but you even remove files in A, which could lead to a disaster, also because you can't notice it, unless you work with the same repository using another client or another Eclipse instance! This is very annoying and serious bug, IMHO, and I can't understand how it can be still open since December 2005 (although I understood that there have been no will to invest in Eclipse CVS support anymore for a long time...).
*** Bug 289913 has been marked as a duplicate of this bug. ***
Bug 289913 describes another scenario that ends up with unexpected state.
(In reply to comment #5) > Bug 289913 describes another scenario that ends up with unexpected state. It's the exactly same situation decribed in my comment #3. This bug has been here for four years now and it's actually a major issue... :-(
Bumping the severity based on duplicate bug 289913.
Is there any plan to work on this serious bug? It is even worst because I just verified in Eclipse 3.5 that if the OLD tag (the one you switched from) is a TAG (and not a branch), if you commit a deleted file the file is actually DELETED from the TAG (that is, the tag is removed from the file!). In other words: Eclipse not only deletes the file from the wrong place, but it even does it if the wrong place is a tag (and not a branch), while I think everyone would expect a tag to be read-only, unless explicitly removed!
Any news on this? Could this be targeted for 3.8?
I agree this should be fixed but unfortunately, right now we don't have the manpower to address it. Please note this bug is tagged with "helpwanted", patches will be accepted.
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.
Hi Lars, I think this bug should make you think about what you want to do with the CVS client. This is a severe bug which I really doubt it was fixed. I don't have CVS any more so I can't test, but here the main question is: does any committer/maintainer want to still support CVS in Eclipse or not? If the answer is yes, I don't think that marking all CVS bugs as "stalebug" will bring any value, since it's normal that they didn't have any activity during the latest years... If the answer is no, then IMHO marking all CVS bugs as "stalebug" isn't useful either, just deprecate the CVS plugin and bulk close all bugs as "WONTFIX" or "deprecated" or something like that... Just my 2 cents... (also spoiled by the fact that I personally don't like these kind of "stalebug" activities ;-)
