I have a set of files which are text files, but contain the ASCII 0 SOH character.
Perforce sees these files as binary. Now, being honest, I don't care what it sees them as, however, recently we have had several occurrences of Perforce giving different people different versions after a new branch is integrated.
The GUI shows version say #2/#2 (two of two) on two peoples workspaces, but they have different versions. When these files are right clicked and diffed against the latest (having selected the character set in the popup to treat them as text), it shows the file as having differences. However, choosing "Get latest revision" or doing a "p4 sync ..." does not update the file.
I have tried setting the file type to "text" and committing and they remain text up until they get branched when they revert to binary.
Has anyone seen this behaviour?
I have tried setting the file type to "text" and committing and they
remain text up until they get branched when they revert to binary.
If the target of an integrate/branch does not yet exist it gets the filetype of the original (in your case text).
If it already exists (in your case probably binary) then the filetype change of the source file does not get integrated - in your case the target still has filetype "binary".
In order to integrate the filetype change from the source file to the target you need the "-t" option when calling "p4 integrate".
It's good practice to always call "p4 integrate" with option "-t".
Related
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.
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
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.
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.
I've managed to use the $Revision$ RCS keyword in Perforce: when I update my file
//depot/dev_projects/main/src/include/version.h it will update my define in the file, nicely:
#define VCS_VERSION "$Revision: #4 $"
That includes the revision for the version.h file.
What I really need is to embed the revision for the folder of my project //depot/dev_projects/main/src/ to the version.h file. So if someone submits a file for example to //depot/dev_projects/main/doc/readme.txt, I would like to see #define VCS_REVISION "$Revision: #5 $" in version.h after I gets the latest revision from depot.
Is there a way to do that?
You have two cases to worry about: exiting files and new files. For existing files (and I'm going to assume you are talking about c/cpp files), you can simply 'p4 reopen' the files with the filetype 'text+k' and then submit those files:
p4 reopen -t text+k //groovy_project/src/....cpp
This would reopen all of the .cpp files in the //groovy_project/src location and make them 'text+k' (the +k means RCS keyword expansion, but I guess you know that since you have keyword expansion working).
For new files, you should use the 'p4 typemap' command. 'p4 typemap' will bring up the typemap in your editor. This form contains a mapping of files to filetypes for new files added to the depot. These are the default filetypes that new files will receive (unless a new file added explicitly uses a different filetype when the file is added). For instance, if you have
TypeMap:
text+k //groovy_project/src/....cpp
in your typemap, all new .cpp files in the //groovy_project/src folder will get the text+k filetype, allowing for keyword expansion.
Note, if you explicitly give a new file a different type than what is found in the typemap, the explicitly specified type is used. Say you had the typemap above. The command:
p4 add -t text ~/projects/groovy_project/src/newfile.cpp
this file would get added to the depot as text, and not text+k.
I hope that this information helps.
EDIT:
After reading the edits to your original question, the short answer is no, you cannot add a revision for a folder. The slightly longer answer is that Perforce doesn't really know about folders/directories. It just knows about files (and therefore the path to the file). Directories are not really individual objects in the database in a way that would make what you want work.
I think you want the $File$ keyword:
http://kb.perforce.com/article/54/using-rcs-keywords
Two questions:
How to make the TortoiseSvn diff tool ignore the EOL style?
How to fix mixed EOL style files during the conversion from PVCS to SVN?
I've just imported a PVCS archive to Subversion using the excellent free Polarion conversion tool. Everything looks fine, there is just one annoying thing that I'd like to fix.
Some of the cpp files in the original PVCS archive have mixed EOL styles (due to the PVCS merge tool). These files (and all their revisions) are now copied into the Subversion archive using the autoprops setting "svn:eol-style=native".
When I use the TortoiseSvn diff to see a difference between two versions I get the error message "Inconsistent line ending style".
The whole idea of converting 10 years of revision history from PVCS to Subversion is to make it easy for the programmers to see what changes were made in the past - and if you need to clean-up an old file manually before a diff is possible, it's not going to work.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed.
Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.
I use WinMerge as Tortoise’s diff tool and it has an option to treat all EOL styles as equivalent.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed. Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.
In the 2009.1 version of Perforce Visual Client for 32-bin Windows, the "Reconcile Offline Work" option does weird things. In the middle box where the "Local files not in depot" should be displayed, I never get anything. What I do see is that the first time I reconcile a folder, it looks like perforce is filling the box with the "local files not in depot" because a list flashes quickly before my eyes. Then all of a sudden, the list quickly disappears into thin air and I'm left with an empty list. Does anyone know how I can get this feature to show me the files that I have not yet added? It seems like the "Modified files" and "Depot files missing from workspace" features work fine.
Also, as a side note, "Reconcile Offline Work" seemed to work fine in the 2009 beta version.
I had exactly the same problem.
The solution for me was obscure but trivial.
I simply changed the root directory of my client workspace from "C:\depot" to "c:\depot".
Yes, that's right, all I did was to change the drive letter from uppercase to lowercase. And, yes, I verified that changing the drive letter back to uppercase breaks it again and that changing the drive letter back to lowercase again fixes it again. So, this is not just a coincidence.
This is almost certainly a bug in the Perforce reconcile feature.
If you look closely at the reconcile paths, they all appear with a lowercase drive letter, even if you specify an uppercase drive letter, so my guess is that the matching algorithm is simply doing a case-sensitive comparison on the file paths. This is appropriate for everything but the drive letter. Their file lister probably always sets the drive letter to lowercase, so an uppercase drive letter on your client workspace root will never match.
This certainly sometimes happens. I seems the problem is likely to occur if I change the workspace view somehow and/or upgrade P4V to new version. So the solution which worked for me in the past was to trash the problematic workspace and create a new one (sometimes have to choose a different name too).
Perhaps deleting the .p4qt and .p4scc in your user home directory can help too.
Incidently, I did have a conversation with Perforce support on the related subject some time ago, and as the problems like this are very difficult to reproduce, therefore there wasn't much that they could do.
I have found issues with long filenames in p4 reconcile
from the base direectory
p4 reconcile ./...
never returned.
but if I cd further up the tree
cd components
p4 reconcile ./...
worked.
I was able to reconcile the whole tree eventually by stepping up directories, depending on how much longer your paths are this might work for you.
I had an instance where p4v showed the visual indicator that files had changes, and doing a diff showed the changes appropriately, but resolve on any parent directory didn't show them.
Those files had been changed by downgrading a library using a unity package install, and their "last modified" date was older than the previously submitted files. On OSX running the touch command on all the files in relevant directories updated all their modified times and reconcile worked after that.
Is there a way to tell Perforce to leave text files alone without setting the file-type as binary? Or barring that, is there a way to tell the Perforce client to diff binaries? Binary usually isn't desirable, because I lose the ability to diff.
To clarify: If I edit and make changes to a *.txt file on my window client, newlines will have CR+LF as per the DOS format. But if I P4 sync on a Unix client, it will have LF only. I need Perforce to keep the format as-is, regardless of where the Perforce client lives.
That said, I do have a work-around: Set file-type as binary; and/or create a branch with text files set as "text", and integrate periodically back into the mainline where text files are set as "binary". But this is an overly-complicated work-around for what should be a very simple problem.
Finally, I'm on Perforce Windows client 2006.2.
Thanks in advance.
Set all of your client/workspace specs to 'unix' line-endings. Then no conversion will take place when you check in on Windows.
See http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/
The Perforce client can handle line ending properly when syncing to different platforms provided you have LineEnd option set properly on your client. Perhaps you have yours set wrong? Open up your client specs and set the LineEnd option according to your needs.
Check out this KB article on their website for more info. Here's an excerpt:
On the server side, Perforce processes
all text files using Unix-style LF
line-endings. Although Perforce stores
server archive files on disk in the
operating system's native line
termination convention (CR/LF on
Windows, LF on Unix), all line-endings
are normalized to Unix-style LF
line-endings for internal Perforce
Server operations such as p4 sync, p4
submit and p4 diff.
On the client workspace side, Perforce
handling of line-endings is determined
by a global option for each
clientspec. When you sync text files
to a client workspace with p4 sync, or
submit them back to a Perforce Server
with p4 submit, their line-endings are
converted as specified in the
clientspec LineEnd section.
When adding text files that you want to be considered binary to Perforce, use the command p4 add with the -t option to override the type mapping table. See the documentation here. The example given there is p4 add -t binary file.pdf.
I have just come across exactly the same problem, but have a better solution that does not involve changing client specs (which are international, and not all of which I have write access to).
All of our clients are Windows PCs, but Cygwin is included within the Perforce Depot. Cygwin is a Windows implementation of Unix, and requires that text files use LF for line endings.
A possible solution for older versions of Cygwin is to mount the root using the "text" option, meaning that files can have CR+LF line endings. However, on upgrading to Cygwin 1.7.9, this no longer worked, as mounts are transient unless they are written into /etc/fstab. I did not manage to make this work.
Luckily, the Perforce Guru sitting next to me came up with the solution of changing the filetype to binary+D, which uses the same RCS incremental patch storage as text files, but without the automatic line ending conversion.
I can diff these "text" files successfully between my local workspace and the depot.
Give the files a different extension.