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