Versioning directories, pluggable storage layers, decentralized databases...these are interesting, but have been tried, and have not thus far proved compelling. Thus far, I have not seen projects move to Bazaar or Monotone because they were fed-up with Git and Mercurial not versioning directories, nor have I heard of people picking Mercurial or Subversion because of their pluggable storage systems, nor do I see people choosing Fossil and Monotone because they have distributed databases. It's not that these aren't good features--some of them, like properly handling directories and renames, are (IMVHO) definite improvements over Git and Mercurial--but rather, they are not by themselves enough to make people switch what they're using.
The real kicker for me is simply the license. All of the major DVCS players right now are GPL licensed. While Git's been pretty accepting of non-GPL compatible implementations (e.g., JGit, Dulwich), the Mercurial team has indicated that it would view any such project in a very dim light, and I can't conceive of anyone wanting to tempt the FSF by trying that kind of thing with Bazaar. Suddenly having a well-implemented closed-source-friendly DVCS could very easily result in a very sharp and immediate uptake among tool companies. This could completely change the game for corporate shops.
However, if all you do is take the file formats and the over-the-wire protocol, and write original code, it can be under whatever license you want. That seems to be what most of the alternative Git implementations have done.
The Git repository format is remarkably simple. I'm confident that if for some reason all copies of Git disappeared (binaries and source) and I needed to keep working with my existing Git repositories, I could cobble together something that would get me basic DVCS functionality in a couple of weeks.
By basic functionality, I mean the ability to check out revisions, view history, make changes to the working copy, and commit them, and to tag and branch and merge. (Heck, it was only a couple of weeks or so for Linus to write the thing once he decided to go for it, and he didn't have the benefit of having a well-designed and documented repository format and wire protocol handed to him).
Any decent programmer could do the same or better. Thus, I don't think Git being GPL is any significant barrier to adoption by people who need a good DVCS in a closed source project.
Monotone (and I believe Fossil) only version files/directories, and just happen to use SQLite as a local data store instead of rolling their own disk format. Veracity on the other hand, sounds like it allows simple databases as versioned objects in addition to directory trees. That's completely different and sounds very cool.
I'm also not sure how necessary it is. For example monotone allows you to configure custom merger programs (intended for if you don't like KDiff3/Meld/etc) and to set a file attribute that prevents it from trying to use the internal line merger, so in theory you could just commit your database file (or disk image containing database files, or ...) and then write a custom merge program for them. But maybe what Veracity has will delta-compress better, and of course you'd get a merger that's already written.
I'm not saying Fossil is bad for not being widely used; just that it's definitely not yet as popular as Git, Hg, and Bzr.
GitHub more-or-less did that when they switched off of Engine Yard (where they were using GFS), but they had to roll their own with RPC calls. That also meant that they had to change Grit, their Ruby git library, to split stuff that had to get executed on the fileservers (where the actual repos are stored) and stuff that can be executed on the server that wanted the information. With pluggable storage layers, they could have changed how they stored the repos without changing their bindings at all.
I think if they aimed it at a git/hg/bzr replacement for OSS projects, they'd fail mightily.
Either way, they have their work cut out for them.
PKI probably would need to be pluggable to meet the variety of project needs out there. I'd imagine enterprise projects would use a corporate CA, some small startups or open source might be comfortable with a quick-start "ring-of-trust" distributed scheme, etc. Github and other hosting providers could offer CA services. Interesting way to prove code ownership in any case.
I'm using git now and it is leaps and bounds better than anything else I have used. (I like Mercurial too but the branching as a clone is somewhat of a deal breaker for me. I know that there are extensions to do this but I like the out of the box philosophy of git.)
Not sure what you mean hg branch Branchname creates a branch in the repo.
Directory tracking seems like a great idea.
Rename tracking on the other hand seems like a fool's errand since there is no sane universal definition of what constitutes a rename; I think what git does with superficial heuristic hinting at the UI level is really the best thing there.
Personally I don't see the use for it. If you want to retain history then merge the file(s) to a different directory/name. More often than not that works more than well enough, whereas proper rename tracking can become a rabbit hole of edge cases, and if you miss even a few you can hose your users.
And who's this "Vera"? (-:
Okay, I re-read that three times, and I still parse that as some form of database versioning (vs. a database where versioning data is stored)... I mean it talks about records and fields, etc. I guess we'll have to wait a bit to see what's supported.
On the other hand, tghw's interpretation could be very on the mark as well (e.g. simple meta data that goes alongside the sourcecode).
When companies do this, doesn't the open source product run the risk of becoming a second class citizen, or even a crippled one with features being implemented in the proprietary product and later migrated downstream or not at all? Isn't this a recipe for conflict of interest?
If they're building add-ons (i.e. apart from authenticated users, premium members can make groups or something like that) then yes, you're getting a conflict of interest. If they'll built a commercial GUI application, or an integrated graphical differ then it will only help develop the dvcs because the ecosystem around it will be larger.
That is a feature I'm looking forward to. Rails migrations alleviate some of the traditional pain here, but don't go very far on actual data. Having a database you can check out with real versioning could be a really, really compelling feature.
