Veracity: The next step in DVCS

One week from today, at the O'Reilly Open Source Convention, SourceGear will be making a big announcement. Today I'm giving you an early preview. We've been building something new. :-)

It's called Veracity.

It's a Distributed Version Control System (DVCS), somewhat like Mercurial or Git.

It has some cool new capabilities no other DVCS has.

It will be open source, released one week from today under the Apache License, Version 2.0.

This project has been consuming the bulk of my time, and I am glad to finally be able to write and speak about it. I'll have a lot to say going forward, but for today I just want to answer some questions we anticipate folks will be asking.

Why build yet another DVCS?

At OSCON next week we will be referring to Veracity as "the next step in DVCS". This description may sound a bit audacious, but it describes exactly what we have built Veracity to be.

Git, Mercurial and Bazaar are all great, but we don't think they are the last word. This model of distributed development is the future of our industry. Things are just getting started. We're building Veracity to push forward.

So let me try to explain how our vision is different from what is available from the popular DVCS tools today.

Please understand that my intent here is not to criticize existing tools or start a war with their fans (especially because Veracity needs to simmer a bit longer before it's ready). I simply know that the easiest way to explain something new is to compare it to something well-known.

Decentralized Database

Veracity goes beyond versioning of directories and files to provide management of records and fields, with full support for pushing, pulling and merging database changesets, just like source tree changesets.

Veracity's decentralized, template-driven database is used for all kinds of administrative data, including user accounts, tags, commit messages, and history. This database is also the platform on which we are building features like work item tracking.

User accounts

Existing DVCS tools have no real concept of user accounts. Enterprise customers need robust administration features like auditing and permissions. Veracity supports these features with a user system built on its decentralized database engine.

Pluggable storage layers

Veracity wraps all the actual storage of a repository in an API. This allows different implementations to offer different tradeoffs. For example, an organization may want to use an enterprise SQL database to store repository data on a central server, while developer desktop machines may use a simpler filesystem-oriented storage engine. You can push and pull changesets across different storage implementations seamlessly.

Hash functions

Just as with Mercurial and Git, Veracity identifies all repository objects using a cryptographic hash of the contents. Veracity supports SHA1 like current tools, but is ready for the future with full support for SHA2 and Skein, at 256 or even 512 bits.

Veracity's default hash is SHA1. Our dogfooding repo is SHA2/256.

Robust tracking for rename and directories

Like Bazaar, Veracity assigns every repository object an ID which remains constant when the object is renamed or moved to a different path. This handles the situation where a developer changes both the contents of a file and its path in the same transaction, and is a critical feature for robust merge operations.

Veracity also tracks directories as first-class repository objects, just like files.

Cross-Platform C

From the beginning, we wanted to make it easy to integrate Veracity into all kinds of other systems on a wide variety of platforms. So we wrote everything in C, with Windows, Mac OS and Linux all on equal footing. We love Python too, but C is a lowest common denominator that can be ported or integrated everywhere we need to go.

Apache License Version 2.0

Current DVCS tools do not yet have much penetration with enterprise customers. This is largely due to lack of features and company infrastructure. But even if Git or Mercurial were enterprise-ready in every other way, many companies will hesitate because of the GPL.

We chose the Apache License Version 2.0 (instead of the GPL) because we wanted there to be no obstacles for Veracity to be adopted in commercial and enterprise scenarios.

Open Source? How are you guys gonna make money?

The core of Veracity will be open source, but we do plan to sell add-on products built on the core.

Does this news mean you are abandoning Vault?

Heck no. Vault is like, 100% of our revenue. And there are still thousands of teams on SourceSafe that need to be rescued from their plight. :-)

We looked hard at the notion of morphing Vault into a DVCS and decided it just isn't feasible. If we had forced the square peg into the round hole, the result would either have fallen short of being a true DVCS or it would have been an incredibly painful upgrade for Vault customers.

Vault will continue to be supported and improved for centuries.

Is Veracity ready for people to actually use?

Not yet.

We are dogfooding Veracity here at SourceGear, but if anybody else tries to use it, they'll be frustrated. File formats, command syntax and APIs are all still in flux. We have a lot of stuff to finish up before we give it a 1.0 version number.

In the meantime, if you need a DVCS that is ready to use now, Mercurial, Git and Bazaar offer you three great choices.

How can I give feedback?

My blog currently does not have a comments feature, but I would still welcome feedback from anyone who has something to say. If you want to say something privately, feel free to email me directly (eric@sourcegear.com). Or you can use Twitter (eric_sink).

We'll be hosting a project mailing list which will be opened next week when the source is released. And we'll have a "modern" website for the Veracity community a bit later.

Coming Soon...

Remember, this is open source stuff, so it's not real until the source is actually available. That'll happen a week from today with the "official" announcement. For now, I just wanted to let you know what's coming.