SCM tools have a profound effect on the day to day life of a developer. These types of systems have either helped or hindered development teams deliver software. SCM systems are like the “hub” of a development team. It’s where teams artifact important work, integrate changes, save important ideas and add features for customers. It’s the center of our development universe!

It’s all about the developers. They need to be free to innovate and get changes out the door quickly. But they can’t if they are stifled by tools that get in the way. Tools need to be able to ENHANCE the software development process. Many people think that source control is just a place to checkin / checkout code. But it’s more than that, it’s where the software development process comes to life. If the SCM system isn’t up to the task of a complex development process, developers can’t innovate.

Sometimes it’s hard to understand that you have a tooling problem, even if it’s staring you in the face. Think of an old pair of trusty sneakers that you have at your house. We all have a pair, they are many years old, beat-up, dirty, torn… but we still wear them. Our feet hurt when we wear them, but for some reason we refuse to get rid of these old sneakers. Until one day (usually after a sprained toe) we decide to buy a brand new pair and after a little breaking in… WOW our feet feel great! Why did I keep the other pair so long?

Software tools are often like this, there is an “if it ain’t broke (too much), don’t fix it” attitude. We often keep tools too long after their expiration date. You’ll hear it from your development team, moaning about the pains of merging code, switching workspaces, checking out … it’s enough to make you cringe. But still we don’t change. Your old SCM is the sneaker, and collectively as a group you and your team have a hard time recognizing when your feet hurt.

Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! You need to trust me on this one, SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases
• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy
• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system. Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

• Merge early and often
• Enforce a workflow for development teams to follow
• Record and have full visibility into all of the changes that were made
• Write build and compiler scripts
• Automate builds, deploys and tests
• Understand the dependencies between projects and code
• Maintain the development environment for a team
• Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At it’s core, SCM answers the question “Somebody did something, how can one reproduce it?” In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!

Back in the day when software development was more linear and proceeded at a more predictable pace with longer project timelines, version control wasn’t much of an issue. In most cases it wasn’t too hard to keep track of code changes, feature developments, and configuration files. If a developer – or even a team – created several different versions, multiple copies could be kept and, with some careful labeling and archiving, any version could be recreated or referred to later on.

But all that changed with the coming of Agile processes and the evolution of the multiple development teams approach, with different developers and teams branching off the main development trunk line to pursue new features or versions and then merging them back into the main line. If keeping multiple file copies could be prone to error in the old linear approach, you can imagine the danger looming with multiple teams working simultaneously. Suddenly, version control software seemed like a really, really good idea.

Now, of course, there are any number of version control software tools, ranging from very basic products such as open source CVS and Subversion, to some really sophisticated and comprehensive products that provide a variety of helpful software configuration management benefits. Regardless of the sophistication of the particular version control software being used, they all provide one critical benefit — the ability for multiple teams in multiple locations to work off the same source code base with minimal confusion and errors.

If you’re trying to sort out the features-and-benefits of version control software, here’s a short checklist of questions that can help you narrow down your choices:

• Simplicity: Is your software development process modest enough for simple, text-based functionality or are you using a more complex, multiple team approach that would benefit from a graphic, browser-type tool?

• Efficiency: Do you spend a lot of time analyzing and resolving merge conditions? If so, consider version control software with a visual tool that can help facilitate frequent integrating and merging codeline changes.

• Collaboration: Do your developers work on code changes individually, with the need to occasionally share code with other developers or team members? Then consider version control software that includes the ability to both keep files in private workspaces and share them openly with other team members.

• Version Control: Are your products subject to frequent, often substantial revisions that could be prone to errors without the ability to reproduce full version histories of all files and configurations?  Then look for version control software that provides time-stamped atomic transactions and an append-only database that prevents information from being lost and makes it easy to roll back code changes to a previous state.

Choosing the right version control software can make a major difference in your software development management, enabling you to get more robust, less error-prone products to market quicker and more efficiently.

You’re starting to hear more and more about distributed version control as some developers implement a new, decentralized version of distributed version control that enables developers to host a complete copy of the repository on their own computers without the need to be connected via a common network.

While this may be OK for smaller projects, there are some inherent risks for enterprise-wide large development projects. In fact, many large companies are loathe to allow their “crown jewels” – their source code – to be copied wholesale across a variety of developers’ machines. Enterprises tend to be genetically predisposed to keeping their files in one centralized location that they know is secure and backed-up.

For projects requiring enterprise scalability, there’s another way to handle distributed version control that’s more efficient, secure, and cost-effective. Developers working locally can simply work from a central server using the company LAN and remote developers can access the repository server through a WAN. If for some reason there’s a geographically-based performance issue, additional servers that replicate the central server can be installed at remote locations.

What’s great about this server-based model of distributed version control is that it nicely balances flexibility and scalability across the enterprise without sacrificing security and file integrity. Here at AccuRev, we’ve got a product called AccuReplica that handles replication and continuous integration for scaling our SCM system so that development teams using the server model can more easily collaborate on parallel development projects no matter where they’re located. In fact, replica servers can be added to handle, say, local and remote departments as well as build clients for easy, appropriate scalability based on your specific needs.

Some of the benefits of using a replicated server distributed version control system:

• Scalability is immediate and easy – set-up involves installing a server and replicating primary server repository with a single command
• Improves collaboration and communication between distributed development teams
• Makes branching and merging easier because all teams, regardless of location, use the same process – no per-site branches
• Administration remains centralized on the primary server – no need for costly resource duplication at each location

So with all the talk about distributed version control, if you’re a big enterprise project developer it’s good to know there’s a DVC server model that utilizes easy-to-setup replicate servers to provide scalable distributed version control across the enterprise without sacrificing flexibility or security.

If you’d like to learn more about the features and benefits of AccuReplica, download the free data sheet.

The holidays are still several months away, but for software development teams in the travel industry, the “hustle and bustle” of the season is already here.

If you think about the ways you make your business or personal travel plans today, you’ll begin to appreciate the increasingly complex software development challenges travel websites present – and the importance of advanced SCM tools.

Just 10 or 15 years ago, many of us were still making travel arrangements through an agent – on the phone or in-person.  We may have gone online to check out a hotel and moved to another site to check on flights – and yet another to rent a car.

Today, travel websites like Kayak and Orbitz bring together all these consumer options and more – and others include frequent flyer miles, preferred guest points and other information related to our travel plans, often involving outside partners.  All of these variables are changing rapidly and are updated dynamically and in real time on travel websites.  This places greater demands on software development teams – teams that are increasingly distributed across multiple time zones and locations.

Also important to note is that the changes and updates these teams are called on to make are increasingly “business-critical.” A software glitch or a site crash can result in major revenue losses, not to mention the residual consumer frustration and damage to the brand.

More variables, more frequent updates and a more business-critical focus — now magnify all this during the many times of peak travel or weather-related interruptions and one begins to understand why more advanced SCM tools are required in the travel industry today.

Basic software development tools may have been fine for some organizations in travel — smaller airlines or hotels with more basic informational web sites that aren’t designed to process high volume reservations and transactions.  But such basic sites are becoming a rarity in the travel industry, leading more and more travel and hospitality businesses to turn to more advanced software development solutions.

AccuRev’s SCM solutions are designed to handle today’s most complex software development challenges, which explains the growth we’re seeing in travel and hospitality business customers.

So when the holidays draw near and you go online to book a hotel, schedule a flight or rent a car, you can thank all of those software developers that have been working hard behind the scenes to make sure the site is up and running 24/7.

Perhaps this is a recurring nightmare that makes you wake up screaming at night – you have multiple development teams working feverishly on making revisions to your most popular software line and suddenly you have NO IDEA where you are with the revised build and all the branching and merging has taken on a life of its own.

I have three words for you – version control system. Those three simple words can make all the difference between going down a nightmarish rat-hole of revisions and having a wildly successful, new-and-improved product launch. A version control system should be an integral part of your software configuration management (SCM) tool so that you and your team members can easily keep track of multiple revisions during parallel concurrent development. A good, comprehensive version control system is critical for development projects that include lots of codeline management and sharing between team members, especially when the teams are geographically distributed or located offshore.

So what makes a really good version control system for multiple revisions?

Well, it starts with stream-based architecture that takes the place of the traditional branch-and-label process. Because streams contain everything associated with a particular file, you can develop a rock-solid history of everything that happens during the revision process, creating an immutable audit trail that’s ideal for both internal audits and regulatory compliance. The comprehensive nature of stream-based architecture also makes rolling back to a previous file version faster, easier and a whole lot safer because the stream contains everything associated with that particular file.

Ideally, a good version control system provides a graphical dashboard that enables you to visually track all changes, making parallel and concurrent development easier and more intuitive. Graphical visualization also makes comparisons of different file versions safer, highlighting differences and minimizing the chance of error. And because visualization makes comprehension easier, merging codelines becomes simpler and quicker by reducing the amount of time spent analyzing and resolving merge conditions. As a result, branching and merging then become easier and more efficient, encouraging innovation while reducing time to release.

If you’re practicing agile software development, then you know the importance of multiple development teams and sharing. With an advanced version control system in place, sharing becomes much easier because developers can safely version in-progress code, store it in a private workspace, and share it with other team members when necessary. This means development teams can operate with greater flexibility and creativity, building features or entire codelines independently.

There’s a variety of different version control system tools available for managing multiple revisions, ranging from simple, basic freeware with minimal functionality to comprehensive systems that provide core version control functionality as well as sophisticated graphical configuration and codeline management. Depending on the size and scope of your development projects, there’s a version control system available that can meet your needs and end the multiple revision management madness.

Source code control is one of those topics that can cause some software developers to sweat profusely and make the veins to pop out of their necks, especially if the project includes working with third-party or vendor code – and these days, what project doesn’t include vendor code?

I should probably start by defining source code control as that mechanism for checking source code in and out of a central repository, enabling several developers to work on the same project simultaneously without the risk (hopefully) of mucking up the source code in the process.

If that isn’t difficult enough already, add vendor code customization to the mix and even the sanest developer becomes a serious candidate for expensive therapy. After all, isn’t traditional branch-and-merge challenging enough without adding a entirely new layer of software configuration management for the vendor code and its corresponding upgrades?

Most of the headaches associated with source code control and management can be attributed to traditional, file-based branch and label source code control tools. The problem stems from traditional branch-based SCM models that require numerous branches to track both vendor source code and custom modifications to that code. Individual branches are needed to track just the vendor code, making merging really unwieldy, especially if you want to do a branch-to-branch merge. Throw in a vendor upgrade and then try to merge a subset of existing custom features and you can see how this can rapidly get ugly.

What’s the answer? Real simple: streaming.

Think of streaming as “intelligent” branching. What makes streaming so great for source code control is that each stream contains every single file needed for that specific source code configuration. They are complete entities unto themselves. Streams can be arranged in a simple “parent-child” hierarchy with a built-in feature that causes configurations to be automatically inherited by every new stream from the parent stream. Even better, the inheritance can also apply to any previous, older streams!

In fact, stream-based architecture provides a host of developer-friendly source code control benefits, including:

• a flexible release process that includes integrated source code control and issue-tracking
• private developer workspaces that enable private versioning  with continual server-backup
• instant, authentic, single-step renaming of any object in the source code control system with full history preservation so no changes are lost

If you’d like to know more about stream-based source code control, especially when using third-party code, we’ve got a free white paper you can download: Managing Vendor Code Customizations with AccuRev’s Stream-Based SCM.

I’m very excited about our 5.2 release! We’ve completed the move to PostgreSQL on the back end, fully internationalized our products, and added a slew of new features, like per-element security so that you can lock down certain files or directories to specific groups or users.

In addition to moving to PostgreSQL, we’ve taken advantage of its capabilities to increase performance in a few key areas such as update, especially when using cross-links, populate, and more. And as a first step towards fully embracing 64bit servers, we now support 64bit CPUs on Linux servers. You can look forward to additional performance boosts as we exploit the capabilities of PostgreSQL in the future.

Haven’t upgraded in a while? Check out what else is new! To get a full flavor of all of the new functionality we’ve added recently, check out recent webinar which highlights what’s new.

If you haven’t tried our plug-ins in a while, we’ve put out new releases of our Eclipse and Visual Studio plug-ins for all versions of AccuRev. Eclipse and Visual Studio plug-ins will work with older releases, so no need to wait for 5.2 to start benefiting from the new features in the plug-ins.

We’ve fully integrated the Web UI into the plug-ins so you can now use all of the following functionality: version browser, annotate, stream browser, and all of AccuWork. Also, in 5.2 you can now access the Web UI with a single click from most screens. For instance, if you want to send somebody a URL of a file or diff, you can just click the “copy to clipboard” button in the toolbar and then compose an e-mail to somebody and paste in the URL. When they click the URL, they will go right to that file or diff. And the Web UI now allows you to print any table that it supports.

While we are in the process of making the new functionality in the Web UI available in all of our UIs, this is a great first step to quickly link to the new functionality.

A Few More Details on What’s Available Via the Web UI
If you haven’t used the Web UI or are using an older version, you may not have heard that there is an entirely new version browser in the Web UI and for AccuWork users- AccuWork on the Web has been completely revamped. For instance, it is easy to search by keyword and you can do drag and drop query editing.

5.3 and Beyond… Here We Come!
The database and internationalization are two very important infrastructure changes which will accelerate both our engineering velocity as well as our market penetration. With our upcoming 5.3 release we will be re-introducing our quarterly pace of releases as we had with our 4.8 and 4.9 releases. With the switch to PostgreSQL and an internationalized code base complete, you will see the release of new functionality faster than ever before. In preparation for 5.3 and beyond, we’ve just launched a new product survey as one of the many ways we collect product priorities. Make sure to look for it and fill it out. It is one of the best ways to have a significant impact on our product roadmap. If you haven’t gotten an e-mail yet, you may not be in our survey database. Just ask your AccuRev administrator for a link.

Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

1. Denial: It’s never going to work (in a timely manner).
2. Anger: Why do I have to do the merge?
3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.

After building your software, do you check-in your generated binary  files? How about the output from test runs? If your software runs on multiple platforms or your test runs take hours/days to execute, you may want to consider storing the output — especially if binary reproducibility is critical.

Example. Consider shipping an application to a customer who 2 years later reports a defect. Can you reproduce their build “today”? Surely you have the exact versions of source files. But are you using the exact build file? Probably. How about the original version of the compiler? Maybe. But probably not. Don’t forget that your compilers get upgraded too — their optimization algorithms or bugfixes can change the binary execution format of your application. Thus, compiling source from 2 years ago may result in an equally functioning application at the user-level, but at the byte-level, things may have changed dramatically — and at a level where runtime defects (performance/memory) rear their ugly heads.

Myth #1: Committing generated  files results in longer checkout times. No developer wants to checkout source code and wait for or be inundated with megabytes of .o, .class, .jar, .war files that they are either never used or are going to be rebuilt anyway.  The AccuRev Truth: Use include/exclude rules on streams and workspaces to control which streams have access to generated objects and who will receive them during checkout.

Myth #2: Committing binary files slows down your CM system. Traditional SCM systems combine both meta data and content resulting in slower performance over time as the number of files increase (think labeling).  The AccuRev Truth: AccuRev stores meta-data separate from file contents and uses indexes to lookup and retrieve contents.  For example, transactions are labeled not files.  Using a card catalog (index lookup) to find your books is always faster than walking the isles (linear scan).

Myth #3: Storing generated artifacts will bloat the repository. Back in the day of wild-west coding, there was little rhyme or reason for where files were saved in the source tree.  The build system would simply compile the files it found, save the generated output right next to the source file, and as long as everything linked & compiled — it worked.  But in todays complex world of multi-layer software architectures, tiered deployments, mixed technologies, and sophisticated build tools, following a convention is almost a necessity (think  ruby on rails, maven, etc). The AccuRev Truth: Organizing the top-level source tree and configuring your build tool can make it very easy to carve out source vs. binary vs. tests vs. scripts, etc.  Using include/exclude rules, end-users can decide at the stream or workspace level what parts of the file tree need to be visible.

The Pattern. In this pattern for versioning generated artifacts, I’ll show how streams can be used to store generated files only in the appropriate stage of development and prevent unwanted exposure to developers.  Two options are present that can also be used in combination.

Option #1: sub-configurations

Option #1: Store and track generated artifacts as sub-configurations isolated from the mainline.   From a baseline snapshot such as a test build or release candidate, create a new child stream to store the generated artifacts.  Then create a second snapshot that represents both source code and generated artifacts. For a single “configuration” you now have two snapshots – one for source only and a second for source + binary.  Furthermore, you can diff these two snapshots to know exactly how the binary configuration is different from the source configuration.  You might also consider storing compiler files, debugging output, test output,the compilers themselves (!), etc.

Option #2: include/exclude rules

Option #2: Store and track generated artifacts directly in mainline but exclude them from downstream access using stream-level exclude rules.   The top-most streams that need access to both source and binary will include the majority or entire filesystem footprint in their configurations.   The first stream that does not need access to generated objects will likely be the candidate to set an exclude rule on the folder(s) that contain those files.  The exclude rule is inherited to all children and grandchildren.

When using exclude rules, it is easiest to set a single rule on a top-level ‘./build’ or ‘./generated’ folder rather than creating a rule for each sub-folder in a large source tree.  Traditionally, make based build systems would generate the compiled files in-line with the source code.  Lately, ant based build systems would package all generated artifacts in a separate sub-tree off the root.  Regardless of your build tool, it’s best to have all generated artifacts in their own tree – it makes it easier to exclude as well as safer to clean!

In practice I see both patterns in use and both have equal merit depending simply on the situation at hand.  Option #1 is commonly used when generated artifacts are not to be included in the official release.  For example, transient or secondary artifacts such as test cases, debugging output, reports, etc.  These files are not promoted up to the release stream.  Option #2 is usually used when the generated artifacts are expected to be included in the official release snapshot.  Thus, they are promoted up through the test/build/release streams.  The build system for these types of ‘uber’ configurations may have multiple release targets creating different levels of release packages such as ‘minimal’, ‘app’ , ‘app-with-tests’ and ‘full’.  That is to say, the CM system may have all possible files but you can choose what actually gets deployed.  Ultimately, storing everything in the CM system may likely be the right choice for audit and reproducibility.

/Happy Coding/