Bugzilla – Full Text Bug Listing
| Summary: | [Doc] Project property for "fetch absent" | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Whitmore <thomasw> | ||||||||
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | hsommer, john.webber, kkumara, wlodzimierz.matzke | ||||||||
| Version: | 3.0 | ||||||||||
| Target Milestone: | 3.1 RC1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 2000 | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Thomas Whitmore
Did you do a refresh in the sync view before doing the update? The sync view will only update incoming changes it discovered during the latest refresh operation (unlike Team>Update which gets the latest). To see the protocol trace of the communications between Eclipse and the CVS server, you can follow the steps at the following URL. If you did a refresh and still are missing incoming changes, perform the refresh again with tracing enabled and attach the trace to this bug. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm- home/docs/online/cvs_features2.0/cvs-faq.html#misc_0 Some number of times I have experienced refreshing both in the Workspace resources and the CVS repository, repeat the commit on the originating machine, etc and still had the update not be detected. Will look for more info & diagnostic next time, thanks for that, regards. I was referring to a third refresh. There is a Refresh with remote in the synchronize view (or is that what you meant whn you wrote "CVS repository"?). We can't dupe, and we would need the trace at the time that you know that the sync view is not showing changes that are actually in the repo. Also with the trace, give us the names of the resources that you think are being missed. Thanks for your help. Though I was referring to refreshing in the CVS Repository Explorer, I'm aware of and use the CVS Sync Refresh button and believe I have used this also in one or more of these problem situations. Somewhat separately, I feel there's a bit a solidity issue with the CVS Client for general Sync usage and for Branching/ Merging. When things go wrong, I've typically copied the source folders to a backup location. Indeed this is now my standard practice before any Branch/ Merge operations are attempted. However, when a Merge fails and I wish to manually bring in work from a backed- up source tree, there seems no operation to Connect my folders into CVS; without unwanted commits on *every* file. Basically Eclipse seems to offers absolute 'Checkout', 'Replace' and 'Disconnect' operations, and what seems to be a relative 'Synchronize' operation, but no absolute 'Connect' operation. Such an absolute operation would determine & correct Local & Remote states of all files, without reference to previous local CVS tags; providing the means to repair damaged states & giving 'operational completeness' of workspaces against CVS state. ... Having experimented somewhat with the CVS preferences, and having used the Sync Refresh with Remote option, I don't believe these are offer an 'Absolute' state operation. They may or may not be close - I couldn't get much useful improvement out of the 'compare content' option - but complete Operability & Repair capability on the cvs state would require that I could specify, for some folder tree, what CVS revision I was installing my source folders into. Based on this it would determine changes with respect to that revision and retag files. I've had to reengineer CVS sync & reintegrate changes manually a couple of times now. One 'window' for problems is to Merging from a branch, and then continuing work in that branch. The Merge operation does not create a new version or whatever tag to define the merged-from point, so further work will not be correctly mergable. The Absolute 'Connect' operation would have been ideal for that situation, as it would be ideal for any and all situations where code has been worked on elsewhere, or restored from backup, or sync has been damaged, and any or all other problem situations. So I'd really be quite keen to see such a capability. I agree that this would be useful although I must admit that I am having a hard time following your discussion above (could be due to lack of sleep on my part;-). Just to let you know, the Team>Share Project options does handle reconnecting projects but could do with some improvements. Could you open an enhancement request for what you asked for above. We prefer not to mix different bugs/enhancement requests in a single bug report. Created attachment 7259 [details]
Trace Log of failed CVS Sync
Unless you've fixed this in 3m6, the problem is still there. I've just posted a trace log demonstrating Sync failing to detect a change. The problem persists despite workspace and sync refreshes. I am not sure whether this is a failure of committal into the CVS system, or a failure of sync/ update to tracking state correctly. If you could indicate what might be going on here, I'd be interested to know. Regards, Thomas This is most likely an issue with CVS NT which is not officially supported. This means that we are willing to track the issue and may fix it if time permits (and it is a problem in out client and not in CVS NT;-). What version of CVS NT are you using? This is version 2.0.11 of CVS NT. Since we're seeing an error coming back from CVS in the log, I'll submit the report to their guy (spoke to him once before). You're right, it could well be the problem there. Perhaps next day or few since their website is not coming up today. On the Eclipse side it would be most useful if files with 'error' statuses were shown in the Sync tree; alerting us that there were problems and allowing manual resolution. Frankly the Progress window is not useful for errors, since they do not have specificity or actionable resolution from there. Thanks again for your help. Hi Michael, I've spoken with Tony Hoyle at cvsnt.org, email tmh@nodomain.org . His comment is that CVS is correctly reporting the existing revision in response to the 'status' command, and that the Eclipse client is then sending an incorrect 'new file' command. http://www.cvsnt.org/cgi-bin/bugzilla/show_bug.cgi?id=212 Quoting Tony: > The Entry line that Eclipse is sending is "new file". There are two errors: > 1. You should never send a "new file" entry to the server - the standard CVS > client explicitly checks for this and avoids doing so. > 2. Since Eclipse has only just updated the file, it *knows* it exists, so why > is there a "new file" entry for that file anyway? > > The resulting status report is correct, if unusual - it sees you've apparently > added a file without going through 'cvs add' and correctly reports that this > cannot work for this file, as it already exists. So I'd be interested to know how this problem can be resolved. Thanks for your help, Thomas I suspect that the problem is due to a difference in the text messages returned by the CVS NT server. The advanced features in the sync view depend on the content of text messages to properly determine the sync state of files (it's unfortunate but that's CVS). As I stated before, CVS NT is not officially supported. However, we try to maintain compatibility. Unfortunately, we do not have time to address this as the current time. Hopefully we will have time in 3.0 to investigate. If you want to help further, what we need to know is: 1) The exact failure case (i.e. what steps result in the failure or what sync state fails) 2) how the CVS NT messages differ from the *nix CVS messages in the failure case If you (or anyone else who is interested) can provide either of both of these, that would be helpful (of course, a patch to fix the problem would be extremely helpful;-) Do you have repository prefixes enabled for you CSNT server. If they are, that could be a cause of the problem. No, no repository prefix is enabled or specified for CVS. Can we identify why Eclipse is attempting to add the file as New into CVS? This is where the error apparently occurs. Are we agreed that Eclipse is getting an erroneous determination of state from results of the 'status' command? We've got a log capturing the occurence and CVS responses, unfortunately I do not have a *nix box to compare different CVS implementations. Where can we take the troubleshooting from here? Regards, Thomas Unfortunately, it is not a simple as that. The Eclipse CVS client fakes a status on a new file in order to determine the actual revision of a file (unfortunately, CVS doesn't offer a better way). I cannot see anything obviously wrong with the trace you included. However, it only takes a small change in the message format of any command (be is status or update) to cause problems. If you provided the exact steps to reproduce with a simple test (e.g. create a project, and a file, etc.) and attach the trace from CVS NT, I could perform the same steps against a CVS server and compare the output. Another option is to use Team>Update as it uses the standard CVs uodate mechanism so is unaffected by text message format changes. I seem to face this problem with CVS running on a unix box and using extssh authentication. Quite often not all the new revisions are shown upon synchronize. Karthik, can you please give more details. What Eclipse version are you using? If you perform a refresh in the sync view, do the revisions appear? If not, can you follow the steps in the URL mentioned in comment #1 when performing the refresh failure and attach the output to this bug. I am also experiencing this with Eclipse 3.0 M6, Windows XP SP1. It behaves
correctly in 2.1.2, however.
1. In Java perspective I select a package and right-click it for "Team-
>Synchronize with Repository..."
2. The Team Synchronizing perspective opens and I see 7 files (new revisions)
due for incoming. There should actually be 8 files (new revisions) due for
incoming as confirmed by SmartCVS and also by doing a "Compare with latest
from HEAD" in Java view. One file is missing in this Team Synchronizing view.
3. "Refresh with remote" in the Team Synchronizing view does not reveal the
missing file. In fact no refresh in any view will show it.
4. Doing an "Update" in the Java Perspective retrieves the file correctly,
however.
I'm using SSH at SourceForge.
I tried enabling logging, but when i synchronized none of the cvs logs showed up on the console. The eclipse version I am using is: Version 3.0.0 Build Id:200312182000 I will try get more details when it happens again. I also enabled the loggin as per the instructions but get no CVS logging either. Strange that the logging doesn't work. As long as you start eclipse using java.exe instead of javaw.exe and include the -debug and -consolelog then you can enable the logging from the Team>CVS preference page (Display detailed protocol output to stdout). I still haven't been able to reproduce this. The next time it happens, please do the logging (if you can get it to work). Another thing to try is this: - make sure that the comparison criteria is set to revision compare (the default) in the drop down menu of the title bar. - dirty the file that should be an incoming change (i.e. modify the file in an editor by adding a space somewhere and save it). The file should appear in the sync view as an outgoing change. If it is a conflict, then that measn tht Eclipse knew of the incoming change but the sync view didn't show it. - Perform a refresh with remote on the project. The file should be a conflict. If not, perform a refresh with remote, directly on the file. If it is still not a conflict, perform a commit on the file. The commit should fail (if it doesn't then that means that there was no incoming change on the file in the first place). I hadn't set Team>CVS preference page (Display detailed protocol output to stdout). This wasn't in the instructions. What I mentioned was an alternative method of enabling logging. Both should work. Logging is working now, but I've lost my test case since I had to do a forced "Update". All I can say is a general statement, that the Team CVS Synch view is sometimes missing some files that should be included as incoming. Trust me, the bug is there! I believe you but there is nothing I can do until I can reproduce it or am given more details about the failure case. All the reports in this bug are rather vague (i.e. they report a problem but do not offer a specific description of the situation or the steps to reproduce). Since it is not happening for everyone, I am assuming that there is something unique to your setup that is triggering the bug. By the way, what is you setup (e.g. Eclipse version , CVS server version, connection method, JVM)? Since it seems to be happening frequently for those who have posted to this bug, my hope is that we can obtain enough information to determine where the failure is occurring. all help in this matter is greatly appreciated. I did post some specs, but here they are again: Eclipse 3.0 M6 Windows XP SP1 JDK 1.4.2_02 public CVS at SourceForge (don't know the version) extssh connection I'll just have to keep an eye open for it. Just a reminder - when I experienced the problem with the missing resoure in 3.0 M6, it showed OK using Eclipse 2.1.2. Michael, Let's have some solidity in the CVS Synchronize operation and UI. If it's so dependent on implementation-specific string matching then let's see an *unrecognized* or error node in the tree for files where no exact match, either positive or negative, is recognized. Attaching the specific CVS sync log for that file to the error node, would also enable prompt diagnosis. Also helpful in making sync more reliable, would be a more relaxed/ tolerant matching of strings or statuses, and/ or a Preferences UI page where the relevant strings could be specified. Basically if you implement the 'unrecognized' sync node and CVS interaction details we'll have the problem probably solved in 5 minutes next time it occurs; and diagnosis in this area will never be troublesome again. Good idea? Regards, Thomas I think it is an excellent idea. Is this bug related at all to Bug 45138? https://bugs.eclipse.org/bugs/show_bug.cgi?id=45138 Someone at our office has seen a similar problem to this. There are two characteristics of his workflow that may be related. He works offline a lot (i.e. at home, he cannot connect to his repository) and uses an external tool (which measnhe uses refresh with local to get his changes into Eclipse). Does anyone else experiencing this problem have these charateristics in their workflow. As per comment #28, we are working on improving the flexibility of our message parsing. We will take you comments into consideration. Michael, well I do work from home and work offline sometimes but I do access the SourceForge repository as well directly in Eclipse 3M6. I don't use external tool. PB In my case we have some generated files which we have to refresh after running the generator (which is run as a seperate application). But the problems seem to occur with regular (non generated)files also. Created attachment 7484 [details]
CVS Log file
CVS Log file, The file SimpleConstraint was modified and commited to cvs, but
when I synchronize, I dont see the file in the Synchronize View.
Created attachment 7486 [details]
CVS trace of synchronize action
A colleague added a new file (export.gif) and edited 4 other files
(folder_closed.gif, folder_new.gif, folder_open.gif, import.gif) and committed
them to SourceForge. I did a "Synchronize with repository" and the Team View
tree only shows one file, "export.gif"
I now see the problem. We have code that determines whether our remote bytes are stale. It assumes that all incoming revisions will be later on the same line of descent. That is, that revision 1.2 will follow 1.1. However, it appears that the initial revision on HEAD can also be 1.1.1.1. I now recall that this occurs after an import. We don't see this when projects are first committed from Eclipse because import is not used. we will need to adjust the logic for determining when remote sync bytes are stale. That's good Michael, I also had another synch error (didn't get the log) where I had a copy of a foobar.java file CVS version 1.6. Colleague committed to new version 1.7. My Resource History for foobar.java clearly shows 1.7 in the History List with 1.6 in the list with an asterisk next to it (my local copy). I then do a "Synchoronise with repository" and it does not add 1.7 to the tree but adds version 1.6 - needs to be updated (incoming) which I already have. Philip, the revision shown in the sync view is actualy the local revision. If you open a compare editor on the file, the left pane title should show the incoming revision. OK Michael, but even though I didn't save the log for that one, I did look at it and it had one of those "RESULT> Status WARNINGorg.eclipse.team.cvs.core code=1" type messages. I suspect that the warning was just indicating that there were E messages from the server. If thefre were any serious problems they would also appear in the Error Log. Is there anything in the error log? Nothing in the error log. I'll keep my eye on it. Assigning for verification. Changes were made to ResourceSyncInfo.isLaterRevision and a test case was added (CVSWorkspaceSubscriberTest.testSyncAfterImport). Fix released to HEAD *** Bug 50382 has been marked as a duplicate of this bug. *** *** Bug 50387 has been marked as a duplicate of this bug. *** Verified, but also raised a separate bug aboug adding tracing to refresh operations to simplify debugging: 1. we could show a dump of remote revision tree found on refresh 2. we could show a dump of reconcilling done by the subscriber See Bug 51708 I'm seeing similar behaviour with Eclipse 3.0.1 (200409161125) on SuSE Linux Pro 8.2 (Gnome). The scenario: a colleague checked in a new directory and several new files in an existing project (using command-line CVS), as well as changes to existing files. I used Team -> Synchronize from the Package Explorer (about 14 hours later), which picked up the changes to existing files but not the new directory with its new files. A command-line cvs update executed some time later showed the new files. Our CVS repository runs on a Solaris box. I'm afraid I can't submit any more documentary evidence at the moment: the bug happens sporadically, rarely more than once a week. The next time it happens I'll try and gather more information. Perhaps this bug should be reopened? This bug definitely still exists in Version: 3.0.1 Build id: 200409161125. Scenario: I came into the office Monday morning. Booted my machine. Started Eclipse. Saw in my mails that a colleague had checked in 3 new files in a new subdirectory of an existing directory in a project. Ran Team -> Synch on the project - the files were not found. Went to a shell, cd'd to the existing directory, executed "cvs up -dP", and the new subdirectory and files were checked out. After a refresh in Eclipse, the files showed up there too. It's getting so that I'm afraid to use Eclipse for any critical CVS operation, like merging or branching. What additional documentation can help you pin down this bug? The next time you synchronize and new files don't appear, do the following: 1. on the CVS preference page (the main one) enable the preference called "display detailed protocol output..." and restart eclipse so that you have a console visible (e.g. somewhere to dump stdout). 2. run the synchronize 3. open a new bug with the synchronize protocol output and the names/paths of the files that were not found. 4. run an update from without eclipse, append output to same bug. Thanks. I also believe this is not fixed (I think my problem is related to this one). I am using Eclipse 3.0.1 (200409161125). I added a branch using eclipse to my sourceforge project. I can see the branch using the eclise used to create the branch (I never did a team->disconnect ...) and I can see it using sourceforge viewcvs webinterface. I cannot see the branch using a different eclipse in a different machine (tested both in linux and windows using the same eclipse build). You can check this here (the branch I want to see is php5): http://cvs.sourceforge.net/viewcvs.py/myhelpdesk/myhelpdesk/?only_with_tag=php5. You can use eclipse with :pserver:anonymous@cvs.sf.net:/cvsroot/myhelpdesk to test. Re: Comment 49: This problem would appear to be unrelated to the original problem reported by this bug. Eclipse does not automatically discover new branches but they can easily be discovered by either refreshing or configuring the tags for a project. This is descibed in the documentation. I'm reopening this per Jean-Michel's request below. To me it looks like Eclipse
should call "cvs update -Pd"; maybe there's some way of configuring this I'm
missing?
The missing files are:
webapps
webapps/sandbox
webapps/sandbox/newsitemap.xmap
webapps/sandbox/sitemap.xmap
webapps/sandbox/no-session
webapps/sandbox/no-session/customerservicenosite-body.xml
webapps/sandbox/no-session/footer.xml
webapps/sandbox/no-session/header-no-session.xml
webapps/sandbox/no-session/html-head.xml
webapps/sandbox/no-session/index-body.xml
webapps/sandbox/no-session/indexregister-body.xml
webapps/sandbox/no-session/login.xml
webapps/sandbox/no-session/menu.xml
webapps/sandbox/no-session/menu.xsl
webapps/sandbox/no-session/nosll.xsl
webapps/sandbox/no-session/page.xml
webapps/sandbox/no-session/page.xsl
webapps/sandbox/no-session/passwordforgot-body.xml
webapps/sandbox/no-session/ssl.xsl
Here's the log from Eclipse's CVS update (synchronize doesn't produce a log):
***
cvs update -P "/jentromanager"
cvs server: Updating .
cvs server: Updating accounting
cvs server: Updating accounting/src
cvs server: Updating accounting/src/java
-- snip, nothing of interest here --
cvs server: Updating voucher/src/test/com/jentro/manager/voucher/persistent/impl
cvs server: Updating xdocs
ok (took 0:34.091)
***
And the log from the CVS command in a shell:
jlw@john2:~/development/jentro/HEAD/jentromanager> cvs up -dP
cvs server: Updating .
cvs server: Updating accounting
cvs server: Updating accounting/src
cvs server: Updating accounting/src/java
-- snip, nothing of interest here --
cvs server: Updating voucher/src/test/com/jentro/manager/voucher/persistent/impl
cvs server: Updating webapps
cvs server: Updating webapps/sandbox
U webapps/sandbox/newsitemap.xmap
U webapps/sandbox/sitemap.xmap
cvs server: Updating webapps/sandbox/no-session
U webapps/sandbox/no-session/customerservicenosite-body.xml
U webapps/sandbox/no-session/footer.xml
U webapps/sandbox/no-session/header-no-session.xml
U webapps/sandbox/no-session/html-head.xml
U webapps/sandbox/no-session/index-body.xml
U webapps/sandbox/no-session/indexregister-body.xml
U webapps/sandbox/no-session/login.xml
U webapps/sandbox/no-session/menu.xml
U webapps/sandbox/no-session/menu.xsl
U webapps/sandbox/no-session/nosll.xsl
U webapps/sandbox/no-session/page.xml
U webapps/sandbox/no-session/page.xsl
U webapps/sandbox/no-session/passwordforgot-body.xml
U webapps/sandbox/no-session/ssl.xsl
cvs server: Updating xdocs
There is a CVS project property for enabling/disabling the -d option (fetch absent directories). Is it off for your project? Is this under Prefererences -> Team -> CVS? I don't see a "fetch absent directories". I see "Prune empty directories" (checked), but can't find the setting you mention. I'm currently using Eclipse on SuSE 9.0 (KDE 3.1), Eclipse Version: 3.0.1 Build id: 200409161125 No it's available from the Properties dialog of the project in the Navigator, Packages Explorer, etc. Choose Properties from the context menu of the project, click and CVs and you should see the option in question. Oh yes, now I found it, and it wasn't checked for that project. Sorry! Maybe this should be a FAQ somewhere? I have updated the doc |