Discussion:
Invalid conflicts
s***@gmail.com
2015-08-19 17:02:10 UTC
Permalink
Something strange happens from time to time. I haven't found a reproducible pattern to it.

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.

Solution, so far, is to delete those files locally and do another cvs update. This pulls down the latest copy from the repository again.

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.

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 the following:

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.

I think that CVS is putting the restored+ in the Entries file. How and why?
Does anybody know how I can stop this from happening?

It's possible eclipse is doing it, but I don't see that in their code.

Does anyone know of why this situation might be occurring? What is the restored+ used for?

Thank you in advance,
Steve
Arthur Barrett
2015-08-24 00:26:13 UTC
Permalink
Hi Steve,

I assume this was a cross post, but info-cvs has stripped out the
eclipse.org destination...

Odd that you can't find where Eclipse is writing this into the Entries
file.

The Eclipse CVS module is always bundled with Eclipse so I wouldn't be
at all surprised to find that some of that code executes even if you
don't have it 'setup' in the Eclipse preferences.

Please do let us know if you get an explanation.

I'm personally of the opinion that the files in the CVS folder are
'private' files for CVS to read/write - they shouldn't be used by other
programs. In the CVSNT project we were trying to write a generic
library for other applications to access these (mostly read-only, eg:
WinCVS and TortoiseCVS) but that wouldn't help Eclipse (because it's not
a pure java API) and established projects didn't look too keen on
re-writing to use it...

Regards,


Arthur
-----Original Message-----
Sent: 20 August 2015 03:02
Subject: Invalid conflicts
Something strange happens from time to time. I haven't found
a reproducible pattern to it.
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.
Solution, so far, is to delete those files locally and do
another cvs update. This pulls down the latest copy from the
repository again.
Looking into the Entries file WRT the files that have
.
.
.
/<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.
A google search for "cvs" and "restored+" turns up several
http://code.openhub.net/file?fid=_IBCr2Z1aMkZnSdH-DyInojKUJ4&c
id=g0mpTskWtaI
&s=&fp=5905&mp&projSelected=true#L0

You will see a line that says the following:

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.

I think that CVS is putting the restored+ in the Entries file. How and
why?
Does anybody know how I can stop this from happening?

It's possible eclipse is doing it, but I don't see that in their code.

Does anyone know of why this situation might be occurring? What is the
restored+ used for?

Thank you in advance,
Steve
Glasgow, Steven R CIV USARMY TRAC (US)
2015-08-24 13:27:59 UTC
Permalink
It was a cross post. Sorry.

Steve


-----Original Message-----
From: Arthur Barrett [mailto:***@march-hare.com]
Sent: Sunday, August 23, 2015 7:26 PM
To: info-***@nongnu.org
Cc: ***@gmail.com; Glasgow, Steven R CIV USARMY TRAC (US)
Subject: RE: Invalid conflicts

Hi Steve,

I assume this was a cross post, but info-cvs has stripped out the
eclipse.org destination...

Odd that you can't find where Eclipse is writing this into the Entries file.


The Eclipse CVS module is always bundled with Eclipse so I wouldn't be at
all surprised to find that some of that code executes even if you don't have
it 'setup' in the Eclipse preferences.

Please do let us know if you get an explanation.

I'm personally of the opinion that the files in the CVS folder are 'private'
files for CVS to read/write - they shouldn't be used by other programs. In
the CVSNT project we were trying to write a generic library for other
applications to access these (mostly read-only, eg:
WinCVS and TortoiseCVS) but that wouldn't help Eclipse (because it's not a
pure java API) and established projects didn't look too keen on re-writing
to use it...

Regards,


Arthur
-----Original Message-----
Sent: 20 August 2015 03:02
Subject: Invalid conflicts
Something strange happens from time to time. I haven't found a reproducible pattern to it.
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.
Solution, so far, is to delete those files locally and do another cvs
update. This pulls down the latest copy from the repository again.
Looking into the Entries file WRT the files that have conflicts, I see
.
.
.
/<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.
A google search for "cvs" and "restored+" turns up several links about
http://code.openhub.net/file?fid=_IBCr2Z1aMkZnSdH-DyInojKUJ4&c
id=g0mpTskWtaI
&s=&fp=5905&mp&projSelected=true#L0

You will see a line that says the following:

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.

I think that CVS is putting the restored+ in the Entries file. How and why?
Does anybody know how I can stop this from happening?

It's possible eclipse is doing it, but I don't see that in their code.

Does anyone know of why this situation might be occurring? What is the
restored+ used for?

Thank you in advance,
Steve

Loading...