November 13, 2014by John Williston, Product Marketing Manager at Perforce Software
This is part 1 of a 6-part series on Git commands.
The 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, 2014by John Williston, Product Marketing Manager at Perforce Software
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
by Sam Stafford, Developer at Perforce Software
As 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, 2014by Liz Lam, QA Lead Engineer (@p4liz)
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, 2014by John Williston, Product Marketing Manager at Perforce Software
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.
November 05, 2014by Marc Hornbeek, Senior Solutions Architect at Spirent Communications
Within an Agile and DevOps environment, Continuous Testing (CT) is the proof of successful merges and continuous integration. At MERGE 2014, the Perforce Conference, I presented our experiences and the best practices we've put in place at Spirent Communications for Continuous-Test (CT) systems. From these experiences and best practices, we have defined the eight attributes necessary for Continuous Test Systems: