P4 Blog

  • November 14, 2014

    MERGE 2014 Laurette Cisneros

    This is part of a blog series designed to explore the stories of our Women in Tech at Perforce. It's been fun and inspiring talking to each one of these women. As they share where they've been and how they came to where they are now, it is my hope that others will be encouraged and inspired too.

    Laurette Cisneros is one of our Perforce veterans. She's familiar with many departments here, ranging from Tech Support to Training to Build & Release. She is a supporter of Girls Inc. and facilitates office participation in Operation Letters to Santa every year.

    Posted In:
  • November 13, 2014

    git-ignoreThe development of intellectual property typically features processes that generate “artifacts”, meaning files important for development that shouldn’t themselves be versioned. In software, for example, this can include precompiled headers, object code, library files, etc. Like many version control systems, Git has an “ignore file” feature. That is, if a file named .gitignore is found in the local folder, its contents will be used to determine which files/folders to ignore when executing Git commands.

    Posted In:
  • November 12, 2014

    Jeppessen MERGE 2014

    At MERGE 2014, Daniel Anolik, a solutions architect of airborne navigation systems at Jeppesen, a Boeing Company, explained how Jeppesen built their own versioned cloud storage system using the Perforce Versioning Engine. This system powers the global distribution of navigation data to most of the world’s pilots. Jeppesen realized early on that hand-rolling their own solution would essentially be re-inventing the Content Management System wheel, yet their survey of existing services proved lacking. It turns out that today’s giant hard-drive-in-the-sky services do a good job of preserving arbitrary amounts of data safely and (sometimes) securely, but none of them can meet all of Jeppesen's requirements out of the box.

  • November 10, 2014

    Perforce IdentifierAs of the 2014.2 release, the ability to limit your view of the depot by changelist number, previously only available to import paths in streams, has been extended to "classic" client specs with user-defined view mappings.

  • November 07, 2014

    This is part of a blog series designed to explore the stories of our Women in Tech at Perforce. It's been fun and inspiring talking to each one of these women. As they share where they've been and how they came to where they are now, it is my hope that others will be encouraged and inspired as well.

    Ksenia Burlachenko is our first Hackbright Academy hire. She's been with Perforce for a little over a year. Originally from Siberia, Ksenia was an economics major from the University of Southern California before joining Hackbright. Her loves range from tech and data to economics to film, and everything nerdy in between.

    Posted In:
  • November 06, 2014

    before git rebase

    Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging integrates changes to another location, such as the mainline. To be more specific, merging takes the contents of a single source branch and integrates them with a single target branch. In this process, only the target branch is changed while the source branch history is retained unchanged. With Git, however, there is the second option of rebasing, which is another way to integrate changes from one branch to another. Rebase accumulates a series of changes into a single “patch” and then integrates that patch onto the target branch. Unlike merging, however, rebasing flattens history because it transfers the work done from one branch onto another, destroying the source history in the process.

    Posted In:

Pages