This seems like a cool solution, I don't know if any of the other big providers are doing synchronized repos, do other similar solutions exist?
This seems like a cool solution, I don't know if any of the other big providers are doing synchronized repos, do other similar solutions exist?
There are places where this is valuable enough to be worthwhile (say.. ANSI SQL and related high-level-language database agnostic libraries). I'm not convinced source control is one of those places.
For fogcreek, they bet the farm on hg and are presumably seeing an opportunity cost to that decision that this mitigates. This makes loads of sense for them. I'm not convinced it's all that awesome for the rest of us, or for either the hg or git user bases as a whole.
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
Bitbucket, the Mercurial hosting service, now also offers Git. Xen, the first major project to use Mercurial, just switched to Git last month. Microsoft has added Git to Visual Studio and Team Foundation Server.
Whatever Joel's personal source-control preferences were, he has to sell into a world where there are more Git users than Mercurial users.
It's unfortunate, as I preferred Mercurial, but then, Git also comes with some advantages to mitigate the disadvantages. They really were closely-matched. Which is why it was a religious war -- it boiled down to preferences.
> Plastic SCM [...] developed an importer that supports the fast-import
> format introduced by Git and widely used to migrate from other systems
Most source control systems assume a one-time import because they are so awesome there's no doubt you'll want to keep your code there forever, but the trend is to support at least Git semi-synchronously.http://codicesoftware.blogspot.com/2013/01/using-plastic-scm...
http://www.perforce.com/git-fusion
http://blogs.msdn.com/b/bharry/archive/2012/08/13/announcing...
Plastic and Perforce are solving a very important, but fundamentally different, problem: how can I use Git to interface with my proprietary SCM? These problems tend to evolve solutions like git-svn or hgsubversion, where either you're keeping the initial repository around as a base (I believe Plastic does this), or you simply don't even care about it at all (e.g., in Perforce, its repos are assembled from arbitrary slices of the main source tree, so the same commit may have different files entirely from the one your neighbor is using, even though both repos include the same chunks of history).
Those are also valuable tools, and we did consider making what would amount to a Git front-end for Mercurial. But we really wanted both systems to be peers, both canonical, and that mandated a totally different set of design decisions and restrictions.
It's not that what Plastic and Perforce have aren't cool. They're just fundamentally different.
edit: Is it safe to summarize what you're saying as 'the best hg-git is kiln' ?