Jump to content


p4 status shows all xtext files as needing to be opened for edit

status reconcile

  • Please log in to reply
16 replies to this topic

#1 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 29 August 2013 - 06:03 PM

After a recent upgrade to 2013.1 (from 2009.2) users have starting using the p4 status/p4 reconcile commands.

The issue some are having is that p4 status shows every single xtext type file as need to be opened for edit.  When you do open the file for edit and then do a p4 diff it shows that there is no difference. So they revert the file at which point p4 status again shows that it needs to be edited to reconcile ...

Some users have no issues:
[1004] doc.kaos 01:47 PM [devbuild:~/depot/mywebsite/css]
$ p4 status
No file(s) to reconcile.

Some constantly get that the file needs to be opened for edit:

$ p4 status
main.css - reconcile to edit //depot/mywebsite/css/main.css#1


$ p4 -ztag status
... depotFile //depot/mywebsite/css/main.css
... clientFile /home/bunny.mcgee/depot/mywebsite/css/main.css
... localFile main.css
... workRev 1
... action edit
... type xtext

Notes:

This is happening to multiple users, but not all users.

Some are able to resolve the issue by forcing a re-sync.

Some are able to resolve it by opening all the files for edit and then reverting them.

Some are not able to resolve the issue.


Does anyone know why this could be happening?

#2 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 30 August 2013 - 04:46 AM

That's very curious; I don't think reconcile/status even knows about filetypes. I'll see if I can repro in-house.

#3 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 30 August 2013 - 02:50 PM

We've got one user left. It's interesting, if they create a new client and sync they have no issues.

Their existing client has an alt-root, so we tried removing it and still had issues.

What does p4 status use to determine if a file needs to be opened for edit? Timestamps between the filesystem and the "have" table?

#4 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 30 August 2013 - 03:25 PM

Just an MD5 checksum I believe. it's already calculated on the server so it's a cheap way for us to check the files locally that way.

#5 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 30 August 2013 - 05:34 PM

Hmmmm ... this users md5sum on the files matches other users ... they appear to be exactly the same. No idea what could be causing all of the files to be tagged as needing edits.

#6 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 30 August 2013 - 07:53 PM

I'll chat with the dev about this. There might be other factors it uses as well.

#7 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 04 September 2013 - 07:13 PM

This is bugging me now because I'm getting it personally.  It isn't just xtext, it appears to just be random files.

It must be using access times or something? I get differences listed for some Makefile's, so I copy them aside, force sync them again and they have no difference and md5sum reports the same for both.

#8 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 05 September 2013 - 04:11 AM

I don't have access to the server code at home, but I'll take a look tomorrow morning and see what it might be.

Can I get OS and application versions for the server and the client? It might help track this down.

#9 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 05 September 2013 - 12:33 PM

p4d is hosted on Linux 2.6.32-220.23.1.el6.x64_64 and is version P4D/LINUX26X86_64/2013.1/610569

The client is using direct access to perforce:1666 (no proxy) and are running on Linux 2.6.18-12.2.1.el5PAE and is version P4/LINUX26X86/2013.1/610569 (2013/03/19)

#10 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 05 September 2013 - 12:35 PM

Oh yeah, another interesting tidbit.
Steps:
  • p4 status -> reports as needing to be edited
  • p4 reconcile -> opens the files for edit
  • diff using p4v -> shows there is no difference
  • select "revert if unchanged" -> p4v does not revert them ....


#11 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 05 September 2013 - 05:58 PM

Ok, if revert/reconcile was generally this broken we'd have a mob outside our doors with torches and pitchforks. Given it happens to multiple users at your site, I suspect there is something wrong with the MD5 hashes stored on your server. I ran through the revert code and it only uses MD5 checksums to compare the files, no dates.

Have you run a 'p4 verify' on your server recently? Here are the details on the command.

http://www.perforce....ref/verify.html

#12 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 05 September 2013 - 06:22 PM

It is very odd ... the users verify that their MD5 Hashes are the same yet one will get that the file needs to be reconciled and the other won't.

I ran a p4 verify -q //depot/... and received no output, so all is good there.

Running the verify without quiet on, I verified a specific file had the same MD5 on the Perforce server as it does in the clients view and it still reports needing to be edited.

I then noted that it appears ALL of the affected files are Revision #1's. We didn't find a single file that was inappropriately asking to be reconciled that was greater than revision #1. (Some were Move/Adds and some just Adds)

Also one client may report it needing reconciling and another client doesn't.  Could it be a problem between the have and have not tables?

#13 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 05 September 2013 - 06:58 PM

o.O

As an experiment, try using the command line client from the 2013.2 beta. There was a lot of work done on reconcile in the 13.2 release. Meanwhile I'll try to repro on Linux. Is there anything else interesting about these files? Text vs binary? Small or large? Given that the verify checked out my next hunch is there is something wrong with our MD5 generation code that is tickled by your environment.

Here's a link to the beta p4. Obvusly no need for the beta server, just the p4 client.
http://www.perforce....ownloads_step_3

#14 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 05 September 2013 - 10:44 PM

This is a shot in the dark -- are you by any chance using the "share" LineEnd option?  And do the files in the workspace have CRLF-style line endings on disk?  And are the workspaces you're comparing checksums against (which have no problems) using the "local" or "win" LineEnd option (i.e. an option where the files go through reversible line ending translation in both directions rather than having their content modified on the way back to the server)?

#15 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 26 September 2013 - 08:50 PM

Sorry! I didn't see this response until today.

That is a difference! The user that is having the issue has their line endings set to "share" all the other users not having troubles use "local", including the users "alt" workspace which is working even thouse his main workspace is not.

The user is not in today, but I will have them check the current line-endings in their workspace on those files.

Nice one!

#16 Doc Kaos

Doc Kaos

    Member

  • Members
  • PipPip
  • 12 posts

Posted 27 September 2013 - 01:31 PM

Verified that if user changes the line-endings in the client spec to local (or Unix) then p4 status shows they have no files to reconcile. :D

#17 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 27 September 2013 - 07:04 PM

Excellent!

Note that if the files are showing as changed when you have a "share" LineEnd but not with "unix", it does mean that they have extra carriage return characters in them (i.e. if you sync them to a "unix" client, which should be getting LFs, you'll get CRLFs).  You can actually fix this just by setting the LineEnd to "share", reconciling, and submitting -- even though it seems like there's no difference, the "share" will implicitly edit the files (during submit) to correct the line endings in the depot, and re-syncing those files should put them back into their correct LF state.





Also tagged with one or more of these keywords: status, reconcile

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users