Community
Participate
Working Groups
At the moment you open the Compare editor after a "Compare With", "Latest from HEAD", the opened file looses its 'edit' state on the CVS server. How to reproduce: 1. Modify (edit notification sent to the server) and save a file. 2. Select the modified file (right click) and "Compare With", "Latest from HEAD". 3. Double click the file in CVS Compare window. At the moment you perform item 3, the server looses the 'edit' state. This happens, because it sends 0 bytes for the file and uses the -C argument for the update. Together they cause the server to think the locally modified file was overwritten and it removes the 'edit' state. Eclipse however did not overwrite the local file, it only uses it for the comparison somehow. This happens only on the first compare, any succeeding compare from within Eclipse does not use this update command. It looks like the file is cached somewhere. Find below the request (>) and response (<) for the one time update that occurs. >Root /data/cvs/test >Global_option -r >Argument -r >Argument 1.1 >Argument -C >Argument -d >Argument -P >Directory . >/data/cvs/test/tzt >Entry /JustAClass.java/1.1//-ko/ >Modified JustAClass.java >u=rw,g=rw,o=r >0 >Argument JustAClass.java >Directory . >/data/cvs/test/tzt >update <New-entry ./ </data/cvs/test/tzt/JustAClass.java </JustAClass.java/1.1//-ko/T1.1 <M U JustAClass.java <Update-existing ./ </data/cvs/test/tzt/JustAClass.java </JustAClass.java/1.1//-ko/T1.1 <u=r,g=r,o=r <29 <public class JustAClass { < <} <ok This has been tested and found with the following combinations: Eclipse (win32) cvs (server), RedHat8 2.1 1.11.5 2.1.1 1.11.5 2.1.1 1.11.6 The project uses Watch/Edit and "Send a cvs edit notification to the server".
Post 3.0
Just a small observation: I can reproduce this problem as described using CVS 1.12.9 via pserver on debian sarge. But I can not reproduce it using CVSNT 2.0.9 on Win2K.
*** Bug 110099 has been marked as a duplicate of this bug. ***
*** Bug 130513 has been marked as a duplicate of this bug. ***
I am suprised that such a serious fault has been open for such a long time. Can I suggest that the severity of this bug is increased to Critical? For users that use CVS Watch/Edit functionality for enforcing informal exclusive locking (as CVS offers no other alternatives) this fault is a major cause of data loss!
You are free to set the severity if you like. The component committers don't set severity. As for your other point, there are a couple of reasons why this bug has not been addressed. The main reason is that the solution to the problem is not obvious. The Eclipse CVS client does a bunch of things that the basic command line client does not (e.g. Synchronization, Comparisons). The implementation of these features uses the "cvs update" command on a fake sandbox which seems to fake out the server into thinking that the user is no longer editing the file. Possible solutions could be: 1) Come up with another way to get the advanced funtionality 2) Track the edited files on the server and re-edit them when the edit state is lost 3) Add support to the CVS server for the advanced Eclipse functionality 4) Remove the advanced funtionality from Eclipse I think that point 2 is impossible and point 3 will never happen. We couldn't do point 4 since the majority of our customers use this funtionality. That leaves point 1 and unfortunately, I don't know how we would accomplish this. That's not to say it's impossible but the solution isn't obvious.
Michael, thanks for the reply - I did attempt to set the severity but BugZilla doesn't appear to allow this on a bug I don't own and didn't raise. Obviously as an end user I was hoping such a severity would translate into an increased priority! You seem to be saying that the Watch/Edit functionality has never and will never work properly, so I'm suprised it has ever been included in Eclipse. I've never seen any warnings or disclaimers about this functionality? From your brief description it does sound like the Eclipse CVS client code's design has some fundamental flaws, but surely a work around can be found? For example, whenever it invokes an "update -C" it could then re-invoke the Edit functionality afterwards? Perhaps it isn't that simple, and it would probably have a performance cost, but the client knows which files are being compared? Alternatively I'm sure there are other ways of getting a specific/latest version of a file in CVS other than "update -C" (although I don't pretend to be a CVS expert).
I didn't realize that there were restrictions on who could set the severity. I've set the severity as you requested. As for the Watch/Edit support, I didn't say it would never work, I said that you can't use Synchronize or Compare if you don't want the edit state lost. You can still use the basic update and commit workflows. As for why Watch/Edit is included, the answer is simple: Eclipse is open source and most of the watch/edit support was contributed by community members. Your point about documenting the shortcomings is well taken. We should add an entry to the readme file. As for your proposal, I would be happy if someone could tell me a reliable and efficient way to get contents without using update. It would be possible to get synchronizations and comparisons using "cvs diff" but this will only work for some files. If we need to use diff for some files and update for others, there wil be a noticable performance impact.
Thanks for updating the severity - I hope this will to more time being spent looking at it. I understand your comments about why the Watch/Edit code was originally included, however isolating it as "highly experimental" might have been a good idea at the time. Not being able to take CVS updates in a controlled manner (synchronise) or double check what has been edited before committing a change(compare) are (IMHO) essential uses cases without which we (as a team) would not be able to use CVS. Restricting compare to text files (supported by cvs diff) sounds a perfectly reasonable solution if it means Watch/Edit will function correctly.
Here is an update to help focus investigation of this issue - on Eclipse 3.1.2 on Windows XP, JDK 1.4.2 and CVS 1.11.18 (on Linux) the "synchronise" functionality itself doesn't cause this fault to be triggered, only the various "compare" options: - Compare with latest from Head - Double click on a file in Team Synchronizing Perspective - Compare with specific revision or version
There is no plan to address this item.
I'm very disappointed to learn that you have no plans to resolve such a long-standing critical fault in the Eclipse CVS plugin. This will force my company, and any others that need some sort of locking in CVS, to move away from Eclipse to alternatives such as NetBeans. That is a shame.
What it really boils down to is priorities. We have limited resources and a lot of work items to be addressed in 3.3. Our main focus is to support the developement of Eclipse.org projects but we do want to support other workflows if the amount of effort is reasonable. My feeling is that addressing this bug would be a considerable amount of work and would require us to drop higher priority items. Traditionaly, it has been the community that has provided patches for the Watch/Edit support. Are you willing to help out with this in some form? If so, we would be willing to reconsider. Perhaps we would be able to come up with a reasonable solution that is not a major rework of how comparisons are done.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
