BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Plastic SCM – DVCS at Enterprise Level

Plastic SCM – DVCS at Enterprise Level

DVCS was born in the OSS ecosystem and is about to cross the chasm to the enterprise world, unleashing new levels of productivity for the happier-than-ever developers embracing it. While Git is king among DVCS enthusiast, many argue it is still not ready for the enterprise, that’s why some well-known tool developers are racing to complete their enterprise-oriented Git wrappers. In contrast, Plastic SCM was born to fill in the blanks that its OSS counterparts didn’t care about and growing from a .NET based, enterprise oriented foundation that doesn’t share a line with the OSS DVCS its competitors are fighting to shrink wrap. What does it have to offer?

Plastic core pillars

Plastic SCM has been designed to cover the following cornerstone concepts:

  • Designed for teams developing commercial software (focused on usability, security and tools).
  • Very strong branching and merging to enable fast feature and task branches (parallel development ).
  • Fully distributed version control (DVCS) Provide visual tools.
  • Integrate with the enterprise infrastructure.
  • Includes a wide set of the required tools used on a daily basis.

Fully distributed is key in the enterprise to enable a wide range of possible working scenarios: from developers working with their local replica (at home, roaming, at the customer site), to distant teams using servers at different locations for speed and flexibility, but always considering the flexibility required by enterprises: distributed when required, and fully centralized when not, with the two models coexisting in harmony.

Visual tools to re-think version control operations searching for more clarity, ease of learning and ease of use. The command line is available too, although all common SCM operations are provided in a visually, trying to reduce the learning curve.

Considering the focus on the enterprise, it us integrated with the enterprise infrastructure which means supporting LDAP, Active Directory, rely on standard database systems for storage and in-house expertise profitability, and scaling servers up and down depending on the work load

A big development effort has been invested not only in the core SCM system but also in the surrounding tools such as diff and merge, so that the full pack is available from the start.

Addressing the enterprise DVCS concerns

If you look at my previous article on enterprise DVCS, you’ll find the typical concerns that arise when most enterprises consider adopting DVCS. The following table explains how Plastic SCM addresses each of them.

Question

Plastic SCM solution

Security wise: is it feasible that each developer has a full clone of the code repository?

Plastic SCM implements partial replica: you can start a branch from a given changeset (commit in Git jargon) and replicate it: you’ll get the entire source tree, but a history only one changeset deep, and you’ll be able to push your changes back. Light replicas are introduced this way.

Auditability

Plastic SCM implements an auditing system that is compliant with SOX.

Policy enforcement

Working policies can be enforced using Access Control Lists: a full list of finely grained permissions allowing admins to tune which branches can be accessed, replicated, which files can be modified, and many more.

Performance & scalability

Plastic SCM servers can handle as few as two concurrent users (with small CPU and memory footprint) and scale to up to 1000 concurrent users (taking advantage of datacenter scale servers)

Operations such as merge, checkin, or adding files (among others) have been heavily optimized.

Huge files

It has been designed to deal with very large files. Large files are split in chunks as large as 4Mb, hence the full file is never loaded in memory and neither server nor client are constrained by total RAM.

Single files as big as 1Tb are used on production servers by specific customers.

Able to work centralized as an option

It can work centralized, with clients directly connecting to the server without the need of an intermediate repository or extra server. A team can have developers working in centralized mode (typically at the office) while other team members use the distributed mode.

Enterprise ready user interfaces

Much of the development efforts in Plastic SCM are not in the core (merge system, versioning, and so on) but the graphical user interfaces. While other DVCS must rely on incomplete GUIs, Plastic provides its own out of the box, developed by the core team as a key part of the system.

Professional support

Provided by a dedicated team, close to the development core, with wide expertise and full customer commitment.

Tools

Plastic SCM includes merge tools, diff tools, code review, repository browsing, and visualization; developed not as optional secondary pieces but as core functionalities.

Focused on visualization and usability

If I had to choose a single feature to describe the visual approach to DVCS of Plastic SCM, I’d definitely go for the Branch Explorer:

(Click on the image to enlarge it)

Figure 1

It is able to render the evolution of a repository, showing the changesets, branches and merge links and enabling the developer to:

  • Diff every changeset or branch
  • Explore the changesets pending to be pulled from remote repositories, and diff them
  • Run merges
  • Create branches
  • Push and pull branches
  • Switch to different branches or changesets

At the end of the day, most of version control operations can be run in a fully visual fashion from the Branch Explorer.

A story of trees and branches

Back in late 2004, months before the version control wars inside the Linux Kernel, a group of engineers wanted to close a gap: huge development teams had ClearCase, good for branching and merging, while small ones had to live with Subversion. They wanted to come up with an SCM good enough to implement "feature branches" and "task branches" for teams building commercial software products and affordable enough for 20 people teams or less.

In November 2006, Barcelona, during the Microsoft Tech Ed Developers event, Plastic SCM 1.0 was first unveiled. It was far from the current 4.1 release, but had a solid foundation: creating branches was fast, easy, efficient, and allowed any team to go for the branch per task pattern. Back then, branches were considered evil by most SCM developers, from OSS to commercial (except ClearCase; not including its UCM version).

Plastic SCM has evolved through many releases, focusing on ease of use, graphical user interfaces, and repository visualization (i.e., Branch Explorer), performance and flexibility, while also heavily investing in one of its core values: merging. Making the merge process as straightforward as possible, yet powerful enough to deal with the most complex cases, has been a long term obsession for the Plastic SCM dev team.

A .NET background

Plastic SCM, as a whole, is written in a variety of languages ranging from C++ to Java, including C# and shell scripts.

Nevertheless, the core of the system is written in C#. At first, the C# choice can seem counter-intuitive for version control software, which sits deep in the developer’s tool backbone. Most of the version control packages out there are written in C/C++ for maximum performance and multi-platform support.

We decided to use C# for its increased productivity, code simplicity, and ease of learning. It paid off: not only is Plastic SCM is able to consistently outperform even the fastest C written version control systems, but the team was able to evolve the product at a pace hard to achieve with lower level languages. Therefore, .NET was key for Microsoft environments while Mono enables clients and servers to run on Mac OS X and Linux. At the end of the day, design is a bigger performance driver than programming language alone.

Specific tools for .NET developers

While Plastic SCM targets many environments, it is clear we’ve put in special effort to target the .NET developers using Visual Studio.

All the operations Plastic SCM can do are available within the VStudio IDE, including the latest VS2012 (Figure 2 shows Branch Explorer running within the latest VS in black theme).

(Click on the image to enlarge it)

Figure 2.Branch Explorer running inside VS2012 in black theme

Pushing and pulling branches, synchronizing entire repositories, running complex merges, browsing repositories, annotating files, diffing changes, and more are operations doable from the VStudio interface.

It is important to highlight the Visual Studio Add-in is able to track files moved across different projects, which is not supported by the API and is solved using the "transparent SCM" capability of Plastic SCM.

One of the most cutting edge features the team is working on is available for Visual Studio users only: the "method history": 90% of times a developer browses the history of a file, he’s really looking for an specific method. Method history parses the C# code across the history of a file, looking for the requested method and displaying how it evolved through time.

Transparent SCM

If you’re working with Visual Studio, Plastic SCM can deal with files moved across different projects, something out of the scope of VS API. We are able to handle this scenario thanks to the "transparent SCM," an initiative we focused on to make common version control operations as unobtrusive as possible.

The goal was to focus on coding, forget about everything else, and let the SCM figure out what you did. You moved a file? Ok, no problem: it will compare your current workspace status against the previous saved one and find modified, added or deleted files. Easy so far, but what about the files being moved?
The algorithm for move detection is quite simple: take all the "potential adds" and all the "potential deletes" and try to match them somehow, if they do match; you have a move.

Let’s now go to the "match somehow." We use the following technique: for each pair we compare the content using the diff algorithm but looking for a similarity percentage factor instead of differences. Are they similar enough? Then they’re the same file and we have a move operation.

This is extremely effective for refactors. Even if you don’t have a plugin, or if your IDE doesn’t track moved files, like VS, Plastic SCM will be able to track what you’ve been doing and make your day a little bit easier.

It is extremely interesting during the refactor process. If you move a class to a different namespace or directory, the similarity factor will be your friend.

Now, one of the clear advantages here is the ability to track directories too: if you move src/kernel into src/render many SCMs out there will produce a list of moves containing each file inside src/kernel. We tweaked the algorithm to be able to detect directory moves too, which is quite convenient in a case like this. Instead of hundreds of files moved, you just get the right directory move. It is true even when you have made changes inside the directory (more renames, added and so on) since it also used a modified similarity factor, this time based on directory operations.

(Click on the image to enlarge it)

Figure 3

The "transparent scm" is based on the Xdiff/Xmerge foundation, which is able to detect moved or modified code inside a file.

(Click on the image to enlarge it)

Figure 4

Method-history

Here’s the deal: 95% of the time you look to the history of a given file you’re just looking for the history of a given method in a class. But since we didn’t have a better tool, we had to go through the entire file history and find our method there.

If we combine traditional version control with programming language parsing technology, we can solve the problem. Here is what you get:

(Click on the image to enlarge it)

Figure 5

In order to "show the history of a given file", Plastic SCM parses each revision of the file, looks for the method, and shows only the piece of code where the method is.

(Click on the image to enlarge it)

Figure 6

Conclusion

Enterprise is the next frontier of Distributed Version Control. Plastic SCM is positioning itself as the only system specifically designed with commercial teams in mind, with ease of use, flexibility, and graphical interfaces built on top of a high performance core as key differentiators.

About the Author

Pablo Santos - President and co-founder Codice Software. Prior to enter in start-up mode to launch Codice Software an Plastic SCM back in 2005, Pablo worked as R&D engineer in fleet control software development (GMV, Spain) and later digital television software stack (Sony, Belgium). Then he moved to a project management position (GCC, Spain) leading the evolution of an ERP software package for industrial companies. During these years he became an SCM expert working as consultant and participating in several events as speaker. Pablo co-founded Codice Software in 2005 and since then he played several roles ranging from core engineering to marketing, business development, advertising and sales operations. Together with David, secured a initial VC round in 2009.

Pablo stepped down as CEO when Francisco Monteverde joined the company, to put more focus on his role as chief engineer, although he continues involved in marketing and key sales operations. Pablo contributes as technical evangelist as main contributor to the Codice's blog, speaker on software events, and occasional writer on different technical magazines. Back in 2004 Pablo joined the regional professional association of computing engineers as vice-dean and moved to dean in 2008, position he still holds. Pablo is an associate professor in the University of Burgos, where he is very involved in the training of young engineers teaching project management including important areas such as agile methods and software configuration management.

Pablo got his Master Degree in Computing Engineering back in 2000 (University of Valladolid, Spain). Pablo has a deep passion for software development but when not coding or designing new features he loves motor-bikes, specially track days, but including long touring trips.

Rate this Article

Adoption
Style

BT