CODEWITHSUNDEEP
perforce
unional
unional

Reputation: 15589

p4 status detects identical files as reconcile to edit

In my workspace when I run p4 status, it marks a bunch of files as "reconcile to edit". However, if I reconcile them and do a diff, all these files are identical.

Does anyone have some idea on what would be the cause?

These files include png, js, php, ttf, xsl files.

I have my workspace configured with: "Allwrite" and "Line ending characters for text files: UNIX" (this is a Windows 2012 R2).

I was guessing the Line ending was the cause, but the files include png, and after I actually submit the changelist and do p4 status, it still report the same list of files (well, I notice a few files are gone, to there maybe something there for whatever reason).

My workspace is new, so the files really shouldn't have any changes.

Upvotes: 1

Views: 1640

Answers (3)

Tao
Tao

Reputation: 14006

The OP mentioned "I was guessing the Line ending was the cause" in the question, but this was a little cryptic for me and I missed how this was in fact exactly what I happened to be looking for.

In related question & answer https://stackoverflow.com/a/49803790/74296, @Samwise explains that the workspace line ending configuration "Shared" can cause this when a file is stored in perforce as "Windows style" line endings.

Upvotes: 0

unional
unional

Reputation: 15589

It seems like there could be several reason for this behavior. @SamStafford answer may surely be one of them.

In my case, it turns out that those files has versions that differ by capitalization. Since Windows is case insensitive, that's what messed it up and always marked them as changed.

Upvotes: 0

Samwise
Samwise

Reputation: 71517

One possible cause of this is that the stored checksums don't match the actual file content. As an admin you can run:

p4 verify -q files ...

to do a server-side comparison of files vs their stored checksums -- if you get "BAD!" results it means they don't match each other (which means they'll also always show up as "different" on client machines since the same checksum is used there). Checksums not matching depot revision contents can be a bad thing (a given revision is supposed to be immutable) and should prompt investigation since it might indicate hardware failure, tampering, et cetera. There may also be benign ways a revision's content can change so it no longer matches its checksum -- one example is if you have dynamically expanded $DateTime$ keywords in the file and you change the server's timezone.

If the content is fine and you want to update the checksum to match, do:

p4 verify -v file

Upvotes: 1

Related Questions