Arthur, Here is what I know so far...sorry to string it across several posts, but I kept finding more information. We are running into a situation where we do a "cvs -q update -d" and several files show the "C". Comparing the files to those in the repository shows NO differences. Looking through the rest in the file shows none of the normal conflict markers. Yet, CVS thinks the file has conflicts. Looking into the CVS/Entries file for those files they have a "restored+" tacked on to the front of the time stamp as shown below in my summary. At this point I don't know where the "restored+ is coming from. Doing a google search for "CVS" and "restored+" finds several links where this string is used in the Eclipse source code. I don't know if Eclipse reading the string from the Entries file and adjusting its variables appropriately, or if it is actually writing the "restored+" to the Entries file. Eclipse DOES read the Entries file, because it notes the proper version of all source files...so it does have the ability to write to those files. In our environment it CANNOT touch the repository because we have not given it the server parameters to connect with. This seems to only happen with our java code which is manipulated with Eclipse and it seems to always be new files to the repository. Our C++ files never have this problem and are manipulated with a host of other IDEs. I have also posted this problem to the Eclipse community with no response yet.
We are using Red Hat Enterprise Linux Workstation release 6.6 (Santiago), Concurrent Versions System (CVS) 1.11.23 (client/server), and Eclipse Luna. The following is a summary of my previous posts: Something strange happens from time to time. I haven't found a reproducible pattern to it. All of our access is through the CVS command line. Sometimes CVS indicates conflicts in files when 1) none of those files have changed locally, 2) some of those files may have been changed/added in the repository, and 3) there are no <<<<< >>>>> markers in the files after the cvs update command. The solution, so far, is to delete those files locally and do another cvs update. This pulls down the latest copy from the repository again and the conflict is gone. Looking into the Entries file WRT the files that have conflicts, I see lines like the following: . . . /<filename1.java>/1.8/Thu Apr 9 19:04:33 2015// /<filename2.java>/1.2/restored+Tue Aug 11 15:41:44 2015// /<filename3.java>/1.2/Thu May 15 16:55:18 2014// . . . The abnormality is <filename2.java>, which is one of the files showing a conflict (that isn't actually a conflict). That file has NOT been modified in the sandbox, and is new to the repository, and has "restored+" attached to the time stamp. This seems to happen only to .java files. We are using Eclipse for development. We have NOT set up eclipse to access CVS in any way (all defaults are in place). A google search for "cvs" and "restored+" turns up several links about this. One of which is: http://code.openhub.net/file?fid=_IBCr2Z1aMkZnSdH-DyInojKUJ4&cid=g0mpTskWtaI &s=&fp=5905&mp&projSelected=true#L0 You will see a line that says, [protected static final String TIMESTAMP_DELETED_AND_RESTORED = "restored+"; //$NON-NLS-1$"]. Clicking on TIMESTAMP_DELETED_AND_RESTORED shows where this variable is used. I think eclipse is just checking for the restored+ string and adjusting their internal variables appropriately, but not sure. I think that CVS is putting the restored+ in the Entries file but don't know how or why. Does anybody know how I can stop this from happening? Could anyone shed a little light on what restored+ is for? It's possible eclipse is doing it, but I don't see that in the code. Does anyone know of why this situation might be occurring? Thank you, Steve
smime.p7s
Description: S/MIME cryptographic signature
