October 18, 2013Perforce
Swarm is designed to help software teams ship quality software faster and every day we add new, useful functionality. We recently got many requests to further enhance our JIRA integration and so we added a couple of enhancements which make life a whole lot better for those using both JIRA and Swarm.
October 17, 2013by Sven Erik Knop, Technical Marketing Engineer
A typical use case for a P4 script is to process some or all spec objects such as client workspaces, labels or changes. For example, I might want to change the options of all existing client workspaces from normdir to rmdir. The workflow would then be:Posted In:
October 15, 2013by Matt Attaway, Open Source Community Manager (@p4mataway)
Clearly having your peers review your code is a huge win for software quality in an organization. It helps disseminate knowledge between team members and a second set of eyes is a great way to keep bugs from going to QA. But what if you had a code review tool that could bring in experts in excellence to give your code a thorough review? Someone who is as fair as a Texas ranger and has the calm of a martial arts master? Someone like Chuck Norris.
At our recent hackathon on the USS Hornet George Georgiev, the dev lead for the Office merge team, wrote a line by line, regular expression based static analysis tool that would analyze C++ code and update a Swarm review with appropriate comments from the Internet's favorite martial artist.Posted In:
October 14, 2013by Ralf Gronkowski, Product Consultant
The Balance of Freedom and Control
A lot of Perforce users really like what they see when I show them Swarm. Almost everybody involved in Software Development wants to do some kind of code review, however, there are discussions on how liberal or how strict a review process should be. In every development process the pendulum swings more towards freedom or more towards control.
October 11, 2013by Mark Warren, European Marketing Director at Perforce Software, @mark_warren
As a Perforce user, what kind of reporting on your development projects do you have? Are you tracking the rate of change in your files? Which files are changing most often? How stable is the project?
If you're interested in that level of understanding, you've probably spent time scratching your head thinking "This information must be in Perforce somewhere, if only I could work out how to get at it."
October 10, 2013by Sam Stafford, Developer at Perforce Software
In the days before streams, it was commonly accepted that if files had different names in different branches, you would need to set up a branch spec that mapped one set of file names to the other if you wanted to integrate changes between those branches. When we began developing streams functionality, we knew we would need to provide another way to handle refactoring within streams, since the branch view used to merge changes between a stream and its parent is dynamically generated and is supposed to be a relatively simple function of the paths specified for each stream – hence we came up with a system for matching different filename variants within a source and target to each other and setting up resolves between them.