|
2010-07-14 13:00:00 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.
|