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:
December 08, 2014by John Williston, Product Marketing Manager at Perforce Software
So what is this NuGet thing anyway? Non-Microsoft developers can be forgiven for asking the question, but NuGet has become increasingly hard for Microsoft developers to ignore in the last few years. There aren’t many projects created in Visual Studio these days that don’t leverage one or more NuGet packages. As somebody soon giving a DevTalk on the subject of Controlling Component Chaos with NuGet and Versioning, trust me when I say that’s a good thing. I remember the pre-NuGet days all too well. I’d learn about some Great New Thing™ (GNT) that all the cool kids were using and positively cringe at the prospect of using it.