P4 Blog

  • June 30, 2015
    With POODLE, Heartbleed and other vulnerabilities in the news, I’ve had many of my customers asking me about the cryptographic protocols used in Perforce Helix. SSL 3.0 is used by many legacy systems and is vulnerable to attacks. However, our Helix Versioning Engine (P4D) does not use SSL 3.0 and supports only TLS 1.1.

    Posted In:
  • June 29, 2015
    In the 2015.1 Perforce Helix release, engineering improved the performance of two distributed version control system (DVCS) commands: p4 status and p4 reconcile (aka p4 rec). The p4 reconcile and p4 status commands were first introduced in the 2012.1 release of Helix. These commands do a recursive scan of your local workspace files, comparing the Md5 checksum of the actual files in your workspace to the checksum stored in the p4d server. Using the results of this scan, p4 decides if files have been added, modified or deleted in the workspace, and marks them for add, edit, or delete as appropriate. It will also figure out if you’ve moved files, even if you’ve made small changes as can happened with refactored Java files.

  • June 24, 2015

    We get a lot of positive feedback about Helix Swarm, but some customers are not sure about all of the workflow steps, so here's a quick review.

    Posted In:
  • June 23, 2015

    I recently had a question about merging files in Perforce Helix that have no direct lineage.

    For example, let's say you want to merge file //depot/main/foo.c (source) to //depot/dev/foo.c (target), which is fine, but you realize the target file was not branched from the source and there is no base (common ancestor). To determine the base, Helix uses integration history created by previous integration commands to know which file revisions to integrate. However, since dev/foo.c was not branched from main/foo.c there is no integration history between these two paths: a baseless merge.  

    Posted In:
  • June 22, 2015

    We’re hitting the road again this year with a series of one-day events focused on better ways to build and secure complex products. These events will prove interesting to professionals at every phase of the product lifecyle and from companies of any size.

    Posted In:
  • June 17, 2015

    Software development projects in bigger companies typically involve large teams collaborating across multiple locations. A large corporation may employ tens of thousands of developers working on thousands of projects over a span of many years. 

    Posted In: