Perforce

[Cori Riska]

Englishspeakers borrowed par force from Anglo-French in the 14th century. Par meant "by" (from Latin per) and the Anglo-French word force had the same meaning as its English equivalent, which was already in use by then. At first, perforce meant quite literally "by physical coercion." That meaning is no longer used today, but it was still prevalent in William Shakespeare's lifetime (1564-1616). "He rush'd into my house and took perforce my ring away," wrote the Bard in The Comedy of Errors. The "by force of circumstances" sense of perforce had also come into use by Shakespeare's day. In Henry IV, Part 2, we find "... your health; the which, if you give o'er to stormy passion, must perforce decay."

I found this thread Support & Status of Perforce Plugin and I looked in GitHub - perforce/sonar-scm-perforce: SonarQube Perforce plugin where latest update was for SonarQube 7.9, merged in November 2019.

I expect it cannot identify new issues / smells that are only in a PR/feature branch, but maybe it can separate branch results from other branches / master - based on tag provided from branch build to the scanner - so that I can compare the coverage level / bugs against master?

Great, thanks Duarte. The info is to help me make the case to use SonarQube. Looks like I have enough now for the next step and we can experiment with SonarQube / Perforce later, when we have our installation.

Currently after I create a release branch, but when we have some time before we release, I sometimes open the entire branch for edit and then lock all files in order to prevent anybody from modifying anything during "code-freeze" period in the release branch.

Is there a better way? Doing it my current way seems possibly like an incorrect use of the lock feature, is there a better way to keep somebody from checking in code without using branches. I though of P4 protect but I am not the admin on this perforce instance, and also dealing with the protect file at potentially 100s of lines would get cumbersome as well.

The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.

p4 protect is definitely the better way to go - it's what it is there for. I would strongly recommend you put all your users into groups, and only ever use groups in your protections table - much easier to manage.

You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:

If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.

The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.

However in my organization I can't be the admin so way of doing this is to have a trigger script in perforce that reads a text file that non-admins have write access to and check whether branch appears on the list. This way admin access like p4 protect would need is not needed.

Perforce registered the new file being added, but did not flag the old file for deletion. It seems like whatever operation was conducted when the renaming happened was not the correct renaming/moving from perforce

I have 1000+ files marked for add that I would like to submit using perforce. During the submit everything seems to work fine but after an hour or so into the submit, using the p4v client, I get an error saying "unable to connect to server...as user... try reconnecting"

This seems to happen every time I the p4v client to submit. Also tried using the commandline and get this message after a while into the submit saying "ssl send failed", "cannot find file specified WSAECONNABORT"

Sounds like the Perforce server is running out of resources. In Perforce, submits are atomic; It either totally works or totally fails. With such a large submit, if the server ran out of memory, or temporary disk space or something, and choked, the submit would fail. As you found, submitting in more manageable chunks doesn't trigger it.

I had a project on Mac and uploaded it to a perforce server. When I got the project from PC all the line endings were changed and now it does not compile on PC. Is there a way to automatically change the line endings like they were before or I must submit again all the project from Windows? Is there any way to make perforce to keep my files AS THEY ARE? I really don't want to have stupid modifications in my source files.

It has to do with perforce, I just edited 10-20 files on MAC to make a multiplatform project to compile. The rest of 140k files were not changed and not even opened on Mac(they were opened by compiler to compile them:P). If I copy the project on PC the line endings are ok.

Line endings for text files are controlled by your client spec setting. You need to make sure that your client's 'LineEnd' value is set properly. In general, this should be left to 'local' which should do the right thing for whatever operating system you are using.

I would check to make sure that LineEnd is set to 'local' for your clients. There is a note on the Perforce Knowledge Base site here that talks more in depth about proper settings for Macintosh clients. That might be a place to start as well to make sure that you have things properly configured on your Macintosh.

Yes you can. Using Unix line-endings for both your clients will tell the perforce clients to leave the files unchanged from how they were submitted. You can also setup a trigger on the server to force it this way, refer to my answer to this question:

Line endings on UNIX, PC and Mac machines are all different. This is what your seeing. Transferring the same file between PC and Mac over any medium would have the same results. You can probably set your editor on the Mac to save the file with windows line endings if you want to get around this another way.

I was wrong "Perforce processes all text files using Unix-style LF line-endings". I'd check p4 client LineEnd value (should be local on both machines I think) and ensure you're using a version of p4 >= 2001.1

I am using perforce and I'm merging a parent stream down into a child stream. The child stream contains files that the parent stream does not (and should not yet). When I merge, it's telling me to delete those files in the child (presumably because they don't exist in the parent).

How can I tell it to stop doing this? In past merges I've just been reverting the deletes but now it's becoming a problem because I'm trying to copy back up from child into parent it's giving me a warning stating that there are outstanding changes in the target.

Files can't be merged from nonexistent sources. Enable the "show deleted files" option and I suspect you'll see that the files exist(ed) in the parent and have been deleted. (Maybe they were mistakenly added and subsequently deleted instead of being obliterated or excluded from the stream?) The merge operation wants to propagate that deletion into the child.

If you want to leave the target unchanged during a resolve instead of accepting the change(s) from the source, select the "leave target unchanged" option. (This corresponds to the "accept yours" option at the command line.) That will mark the source (in this case a deleted revision) as having been "ignored" and after you submit the ignore revision (i.e. an integrate revision with an ignored resolve action) it won't ever come up for merge again until a new revision is submitted to the source. If you just revert the file, nothing is recorded and so the source revision will remain outstanding for next time.

It appears that you must merge or copy down all "delete file" records before it is safe to add any files of the same name. This means all streams must have the delete (or rename) change merged/copied into them before any stream can safely add (or rename) a file of the old name.

So this is odd for me and occurring multiple times now. I set up an perforce workspace copied from the MASTER and then it works for a few days then one day it just shows the hard drives where it should show the WorkSpace root folder.

Funny enough, I ran into this issue today.If someone has this issue make sure that in the top right of the Workspace area, the filter is set to "Workspace Root" and not "Entire Computer". The filter looks like a little funnel for those who don't know.

The fact that you don't have permission to modify it AND it's changing out from underneath you makes me wonder if you might be using someone else's workspace. Is your username in the "Owner" field? Generally each user should have their own workspace(s).

I want to use IntelliJ in the following manner. A Project (akin to Eclipse workspace) that contains multiple modules (akin to Eclipse Projects). As you can guess I am moving over to IntelliJ from a more recent Eclipse background.

3a8082e126