Jump to content


briand

Member Since 30 Jun 2014
Offline Last Active Today, 12:55 AM
-----

Posts I've Made

In Topic: I cannot/may not report errors to the Perforce support anymore

06 December 2017 - 12:10 AM

There have been many changes like this since Perforce was sold to an equity investment company. Many things that were taken for granted 2-3 years ago are no longer common place.

In Topic: Missed Integration

01 November 2017 - 12:33 AM

Here are a couple of suggestions that help me when I'm managing bulk integrations:
  • Make sure to do the integration in a clean/empty workspace. If files are open for edit, that can cause surprises. If files have been added or modified outside of Perforce, that can cause surprises. To avoid these surprises and to eliminate yet another item that I need to double-check, I use dedicated workspaces for my bulk integrations.
  • Make sure the client doing the integration has SubmitOptions set to submitunchanged. If I'm doing an integration, I don't want to have to think about if the integration caused the file to change or not. I just want the integration to happen. If SubmitOptions is set to revertunchanged to leaveunchanged, then I may not get all the changes integrated (in particular, those changelists that did not change the file or its attributes).
  • Avoid mixing single change integrations with integrations of all changes up to change X. In fact, I try to avoid single change integrations as much as possible. I've had to clean up too many problems caused by engineers integrating change X+1 before integrating change X.
In addition to the revision graph that Sambwise mentioned, I also use p4 interchanges -f to give me more information about what is causing my integration problems.

In Topic: Restricting access from a proxy.

05 October 2017 - 12:14 AM

I contacted support, but didn't end up with any useful help.

After spending even more time going over the documentation again, it finally dawned on me what my problem was. I was trying to restrict access based on the IP address of the proxy, but Perforce only allows you to restrict access if the client is using a proxy (any proxy). Take a look at the IP address I listed in the protect table rules and match it up with the addresses in the log line. The protect table rules mentions the proxy's IP address, not the client's. If I changed the IP address in the protect table to be the client address, things worked as expected.

In the end, I concluded that the Perforce protection mechanism would not allow me to configure protections the way I needed, so I resorted to layers of firewall rules to mask the client IP address (setting it to a predetermined value). This allowed me to write protection rules to accomplish what I needed.

In Topic: Basic backup/recovery question

22 February 2017 - 09:28 PM

Thanks all for your input. My upgrade went fine. The only issue was with reseeding the replica. I couldn't use the same checkpoint/journal I used for re-creating the master (one of the tables would end up with a bad checksum). I had to re-create the master first, take a second checkpoint from the updated master, then reseed the replica from that. That added several hours to the upgrade process, but in the end it worked.

In Topic: p4 integrate -b mybranch -c 1234

18 February 2017 - 12:17 AM

Sambwise covered most of what you need. The one thing I'll mention is updating the protections table, if you use it.

In my case, each branch has entries in the protections table, so that I can disable submissions to the branch, when necessary (once we ship a release, we don't want inappropriate checkins confusing things, so we make the branch read-only).