December 18, 2014New Releases of Perforce Cluster Manager, Perforce Eclipse Plugin and P4Java API; Open Source Tools in Perforce Workshop; New Partner Integrations
Murtaza Amiji, Senior Director of Product Management
Here's what's new from Perforce in December.Posted In:
December 18, 2014by John Williston, Product Marketing Manager at Perforce Software
This is part 6 of a 6-part series on Git commands.
One problem commonly encountered when using Git in the context of Continuous Integration (CI) and Continuous Delivery (CD) is server load. Because Git’s design includes everything in each copy of a repository, every clone gets not only the files but every revision of every file ever committed. It isn’t hard to imagine how that can quickly become a bottleneck with expanding numbers of build, test and deployment pipelines.Posted In:
December 17, 2014by Robert Cowham, Senior Consultant at Perforce Software
Continuous Delivery (CD) has been an interest of mine for many years. It has been a pleasure to organize the resources and links below.
1. Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Those luminaries were steeped in practices ranging from Extreme Programming, SCRUM, DSDM to Feature Driven Development.
December 12, 2014by John Williston, Product Marketing Manager at Perforce Software
Why create a new distributed version control system or DVCS? The development world already enjoys Bazaar, Mercurial (my personal favorite), and of course the 800-lb. gorilla in the DVCS room, Git. So why would Perforce set out to create a new DVCS in light of all those options? That’s probably the first question on some minds after the announcement at our MERGE 2014 conference in September. So this series of blog posts is written in the hope of making clear exactly why we’re building a new DVCS, what it will provide the market above and beyond existing products, and provide insight into the choices and challenges along the way.Posted In:
December 11, 2014by John Williston, Product Marketing Manager at Perforce Software
This is part 5 of a 6-part series on Git commands.
A relatively little-known Git feature is its support for both client- and server-side hooks for automation. That may seem strange, for a fully distributed version control system with no proper sense of a privileged “server”, but it’s nevertheless possible to configure processes to run in the “server” sense as the result of a push. Working with hooks is a matter of writing scripts in the .git/hooks folder for a repository, so it’s straightforward for those accustomed to DevOps tasks. Client-side hooks are available for pre-commit, pre-rebase, post-checkout, and post-merge, etc. which provide a fair amount of flexibility. In contrast, server-side hooks are limited to pre- and post-receive as well as an update script that’s run once for each branch being updated. Consider the following example script:Posted In:
December 10, 2014by John Williston, Product Marketing Manager at Perforce Software
This is part two in a series of blogs about migrating source code from one version control system (VCS) to another. Part one was about migrating code from Subversion to Mercurial, in case you missed it. This time we’re tackling something a little trickier: migrating from Visual SourceSafe (VSS) to Mercurial.
The Mercurial site has a page that describes two possible approaches, and for whatever it’s worth I found the second more direct and easier than the first. The only real down side is that you need Visual SourceSafe set up and working, which I no longer had. So here’s the high-level view of the procedure:Posted In: