Community
Participate
Working Groups
I begin to see this bug some weeks ago. What happens: I synchronize, it shows some outgoing changes, I double-click the file on synchronize view. It opens the compare editor, but in remote pane, it compares against a wrong revision (it appears to be always the revision on HEAD), instead of the current revision. Apparently the other operations (commit, etc...) work fine, it appears to be only a "wrong revision on compare" problem. Some characteristics from my environment that I hope can help to track this issue: - My server is a CVSNT 2.5.01. - There are a lot of projects on repository (>50). - There are many branches created. - There are some branch of branch created.
Created attachment 54072 [details] Screenshot of compare editor
Created attachment 54073 [details] Screenshot of compare editor
Created attachment 54074 [details] Screenshot of compare editor
More information: since I begin to note this bug, I have seem sometimes in the remote pane a message like "There is no cached contents for this... <I don't remember the remaining of message>". Double-clicking the file again on synchronize view appears to fix this problem. I'm not sure is this is somewhat related...
*** Bug 164961 has been marked as a duplicate of this bug. ***
*** Bug 164962 has been marked as a duplicate of this bug. ***
Looks like a dup of bug 163949. If you're not working on a partial branch (i.e. parts of the local project on different branches), then please let us know. *** This bug has been marked as a duplicate of bug 163949 ***
(In reply to comment #7) > Looks like a dup of bug 163949. If you're not working on a partial branch (i.e. > parts of the local project on different branches), then please let us know. Michael, I'm not working on partial branches. My branches are all based on entire projects.
Apparently it is not a dup of bug#163949. Should I reopen?
Reopening (although probably still related, does not appear to be an exact duplicate).
Created attachment 55599 [details] Screenshot of the cache error This is a screenshot of the situation I mentioned on comment#4. I'm inside a branch, where revision 1.3 is the latest (with modifications). I synchronized, and after double-clicking it, it attempts to compare with revision 1.9 (the latest of HEAD) and shows that message. After I close this compare editor, and reopen, it does not presents the message, but presents the compare editor of 1.3 against 1.9.
Michael, this is happening in many machines here, with different projects/branches. I'm willing to help you with this, since this is preventing us to use the compare feature we use extensively. Can you point me where in the source code this bug can be? Then I can try to reproduce in a debug session.
In regards to the failure to cache, it is odd given that we explicitly fetch the contents beforehand. It sounds like the cache has a bug where it says it has the contents cached before the compare editor opens and then somehow looses the contents when the compare editor is shown. I suspect the problem is related to the timeout we have for cached contents (i.e. perhaps we don't purge the cache properly and thus leave it in a bad state that gets cleared the first time you open the compare editor). This seems to be a separate issue that is less important the original issue (i.e. it is clear that something is wrong and reopening the editor fixes the problem). Could you open a separate bug report for this? In regards to the original issue, there are a couple avenues to explore here: 1) You could trace the client/server communication involved with the Synchronization to see what is passed. Here's a link on how to do that: http://wiki.eclipse.org/index.php/CVS_FAQ#Is_there_any_equivalent_to_CVS_CLIENT_LOG_is_Eclipse.3F 2) I noticed in the screenshot that you were using change sets. Does the problem happen when using a different model (e.g. Workspace or Java)? 3) Does the problem occur with the old Sync? I suspect it doesn't but it is good to confirm. See the following link for a description of what I mean by "Old Sync". http://wiki.eclipse.org/index.php/CVS_FAQ#Synchronizing_has_some_regressions_in_Eclipse_3.2._Why.3F 4) As for source code, I would need to know the answer to question 2 and 3 before I can pinpoint a good location to debug the problem.
(In reply to comment #13) > 1) You could trace the client/server communication involved with the > Synchronization to see what is passed. Here's a link on how to do that: > I'll try. > 2) I noticed in the screenshot that you were using change sets. Does the > problem happen when using a different model (e.g. Workspace or Java)? In my machine I'm using change sets with Mylar, but there are other machines using just the default team/CVS configuration, because they use Eclipse only as a CVS client for other IDEs. > 3) Does the problem occur with the old Sync? I suspect it doesn't but it is > good to confirm. See the following link for a description of what I mean by > "Old Sync". > Yes, I made some tests and apparently it is a problem with the new model-based synchronization. I just turned off "Allow models to participate in Synchronizations", dropped all synchronizations, restarted Eclipse. I did this on 3 machines and apparently it worked. But we'll continue to observe if this happens with this option turned off.
(In reply to comment #13) > This seems to be a separate issue that is > less important the original issue (i.e. it is clear that something is wrong and > reopening the editor fixes the problem). Could you open a separate bug report > for this? Done. See bug#167964.
(In reply to comment #13) > 1) You could trace the client/server communication involved with the > Synchronization to see what is passed. Here's a link on how to do that: Good news, tracing the communication, I see that when model-based synchronization is on, there is a explicit get to the HEAD revision when double-clicking the file to open the compare editor: CMD> cvs update -r "1.9" -C -d -P "<file-name>" With the model-based off, it get the right revision. If you want to see the full communication trace, I can send it to you in private.
The question is, where did it get that revision. Does the entry in the sync view show the proper revision?
(In reply to comment #17) > The question is, where did it get that revision. Does the entry in the sync > view show the proper revision? > Yes, it shows <resource name> - 1.3.2.1 - 1.3.2.1, where 1.3.2.1 is the latest revision from branch, and on compare editor it shows 1.3.2.1 on left pane and 1.9 on right pane, where 1.9 is the latest from HEAD.
Michael, if you need more information and/or make some test, feel free to ask me.
Unfortunately, I am still not able to reproduce this. I assume that the fact that there is a workaround makes this less critical. However, if someone who is experiencing this wanted to debug it, the first place to look would be in the ResourceSaveableComparison$ResourceDiffCompareInput#getRightContributor (in the 3.2 codebase). This is the code that determines what revision is used for the right side of the comparison. In 3.3, ResourceDiffCompareInput is root level class (i.e. not internal to ResourceSaveableComparison).
Update: I'm debugging now, and it is getting to line 107: "diff = (IResourceDiff)twd.getLocalChange();". Examining "diff.getBeforeState()" returns a CVSResourceVariantFileRevision, whose variant.syncBytes field contains a "1.9" string encoded, which corresponds to the HEAD revision. So I'm assuming the bug occurs before this method and I'll go up. Let me know if there are other interesting places to see.
I tracked changes on difftree and apparently the only thing that is changing across compare openings is the syncBytes value from RemoteFile. I tracked the changes to this field and I found a suspicious code at line 403: // Make sure the sync bytes match the content that is being accessed syncBytes = newSyncBytes; I found on case where the actual contents of syncBytes with revision 1.3.2.1 from branch is being replaced with another array from cache, with the value "1.9" on revision.
The real question is where are the wrong sync bytes coming from? Here is a link to instructions on getting a client/server communications trace: http://wiki.eclipse.org/index.php/CVS_FAQ#Is_there_any_equivalent_to_CVS_CLIENT_LOG_is_Eclipse.3F It should reveal exactly what Eclipse is sending to the server and what the server is sending back. This may help determine where the 1.9 is coming from.
It appears to be coming from the server, on what looks like to be the lastest command executed after synchronization. Following is the snippet of the latest part of traffic, where I substituted the problematic file name by "xxxx.cpp", and the cvs path by "/repository/myproject". The HEAD revision is 1.9 and the branch revision is 1.3.2.1. CMD> cvs update -C -d -P "xxxx.cpp" Argument -C Argument -d Argument -P Directory . /repository/myproject Sticky TR1_4_1 Entry /xxxx.cpp/1.3.2.1///T1.3.2.1 Modified xxxx.cpp u=rw,g=rw,o=r 0 Argument xxxx.cpp Directory . /repository/myproject update MT +updated MT text U MT fname xxxx.cpp MT newline MT -updated Update-existing ./ /repository/myproject/xxxx.cpp /xxxx.cpp/1.9//-kkv/ u=rw,g=r,o=r 66004 ok RESULT> Status OK: org.eclipse.team.cvs.core code=0 ok null
Here's the trace I get using CVSNT 2.5.03 which is what is expected. Have you configured the server as described here: http://wiki.eclipse.org/index.php/CVS_FAQ#How_do_I_configure_CVSNT_to_work_with_Eclipse.3F Anyway, I can't see any difference in the trace that would indicate why your case would behave differently. From this, I can only conclude that the cause of this is a bug in CVSNT. CMD> cvs update -C -d -P "my.properties" Argument -C Argument -d Argument -P Directory . /cvs/repo/MyJavaProject Sticky Tbranch_20070112 Entry /my.properties/1.1.2.1///T1.1.2.1 Modified my.properties u=rw,g=rw,o=r 0 Argument my.properties Directory . /cvs/repo/MyJavaProject update MT +updated MT text U MT fname my.properties MT newline MT -updated Update-existing ./ /cvs/repo/MyJavaProject/my.properties /my.properties/1.1.2.1//-kkv/T1.1.2.1 u=rw,g=rw,o=rw 16 ok
I did some tests here with a test installation, and finally got the steps to reproduce: - Install CVSNT 2.5.01. - Create a new Java project and share it with your repository. - Create a class. Commit and tag with R1_0_0. - Modify this class. Commit and tag with R2_0_0. - Replace with version R1_0_0. Create a branch from this version, and start working on branch. - Make some modification on the class. Commit. This will create revision 1.1.2.1. - Make some modification. Synchronize. - The class will appear on synchronize view. Double-click to open compare. - It will compare against revision 1.2 (HEAD) instead of 1.1.2.1. I'll test with 2.5.02 and 2.5.03 and see if something changed. And yes, it is configured according the instructions.
That is funny. I just tested with a 2.5.03 installation and it works perfectly. I wasn't able to test with 2.5.02 because I didn't find it on CVSNT site: http://www.cvsnt.org/archive/ Also, I wasn't able to find any changelog on (confusing) CVSNT website to confirm if this was some fixed bug. What I don't know yet is why it doesn't happen on old synchronization mode.
(In reply to comment #27) > What I don't know yet is why it doesn't happen on old synchronization mode. > Also, one thing I noted is that when you disable "Allow models to participate on synchronizations" you have to restart Eclipse, instead of just dropping the synchronization and recreating it, for this workaround to work. Is this considered a bug?
I'm not sure what you mean. Could you elaborate on what you tried before restarting Eclipse? The old Synchronization will stay in the view unless it is specifically removed (there's a remove in the view menu). Is this what you mean?
(In reply to comment #29) > I'm not sure what you mean. Could you elaborate on what you tried before > restarting Eclipse? The old Synchronization will stay in the view unless it is > specifically removed (there's a remove in the view menu). Is this what you > mean? > I'm talking about the workaround, which is to disable the model-based synchronization. I was testing this bug with new model synchronization and I wanted to revert it to the old behavior. So, I unchecked the box "Allow models to participate on synchronizations" on CVS synchronization preferences, accessing it through the "Synchronization" view menu. I dropped the synchronization (the "X" on view menu), and synchronized again. But it was not enough, because the compare editor on the new synchronization contents still presented the bug (although the model-based sync is disabled because the model drop-down does not appears on view toolbar). Perhaps something to do with the cache... On this case I have to restart Eclipse for the synchronization to work.
So what you are saying is that you did revert to the old behavior but the "bug" didn't go away until you restarted Eclipse. The underlying data for the two sync types is the same so what you say is possible. However, the data is persisted across restarts as well so I'm not sure why a restart would make a difference. I'm not sure if it is worth pursuing that at this time. I am more interested in the original problem. Are you saying that the problem does not occur in the latest CVSNT build?
(In reply to comment #31) > So what you are saying is that you did revert to the old behavior but the "bug" > didn't go away until you restarted Eclipse. The underlying data for the two > sync types is the same so what you say is possible. However, the data is > persisted across restarts as well so I'm not sure why a restart would make a > difference. I'm not sure if it is worth pursuing that at this time. Yes, I suspect it is some "side-effect" of the original bug + some other unknown cache bug. > I am more > interested in the original problem. Are you saying that the problem does not > occur in the latest CVSNT build? > Yes, it does not happen on 2.5.03.
The problem was caused by a bug in the CVSNT server.
Michael, I understand that it is not worth to make "workarounds" on Eclipse side just because of CVSNT faults, so I think the recommendation on this page: http://wiki.eclipse.org/index.php/CVS_FAQ#What_server_versions_of_CVS_are_supported_by_Eclipse.3F is not entirely true anymore. I'd like to know what version is officially "supported", and by "supported" I mean: the version used on your tests. 2.5.03?
We do not test against CVSNT at all. CVSNT was promoted to supported because the main CVSNT developer made an effort to address several incompatibilities between CVS and CVSNT. Since we do not use CVSNT ourselves, we rely on the community to ensure that compatibility is maintained. I will update the support version number for CVSNT on the FAQ (although you could do it yourself if you like since anyone who can comment in bugzilla can update the FAQ).
I added a note to http://wiki.eclipse.org/index.php/CVS_FAQ#What_server_versions_of_CVS_are_supported_by_Eclipse.3F section pointing to this bug.
Thanks.
