Kiln Harmony is complicated, and has lots of edge-cases it needs to handle. We'll be publishing a whole series of blog posts that explore exactly how Kiln Harmony works. In the mean time, though, just because I think it might spawn some interesting discussion, here is a non-exhaustive list of edge-cases we translate:
* Git octopus merges
* Mercurial descriptions that are not UTF-8
* Git commits whose messages aren't in their nominal encoding
* Mercurial and Git having invalid timestamps
* Git having a different author from committer
* Git and Mercurial commits and changesets with extra metadata
* Mercurial usernames that are not valid Git usernames
* Mercurial bookmarks that are not valid Git refs
* Mercurial named branches
* Git annotated tags (requires an not-quite-yet-released extension to fully round-trip; the non-annotated part of the tag works today and will be forwards-compatible)
* Mercurial changesets/manifests/filelogs with bad parent data
* Git trees that are just flat-up invalid
* Subrepos and submodules (100% preservation, but we can only
translate Git submodules/subrepos cleanly to/from each other,
since Git submodules have to be Git)
There's more, but hopefully that gives you some idea what we were up against. Again, I'll be publishing a series of articles that explore how we handle all the above edge-cases beginning really soon.
I'm really looking forward to these posts - it seems like a lot of the problems you would have faced are specific examples of more generalized data integration issues. Accordingly, the approaches used may have more general applications, which would be cool to tease out from your implementations.
This sounds like a great list of the technical challenges for Kiln implementors (applause) and an awesome list of reasons for me to rationally convince my team (if I had one) to use the single DVCS.
Anyone intelligent enough to use git or hg should be pragmatic enough to learn the other one for the benefit of the smooth workflow, when presented with this list ?
I'm actually really happy with the workflow we came up with; that's something we've been using for months now at Fog Creek with no real issues. The above is a list of data format issues, which your team doesn't have to deal with.
What test cases do you use? Oddly I do not know what cases the git / hg devs use so I would be interested in seeing test cases plus comments as much as anything
We have a fairly robust test-suite that covers all the corner cases we were able to find by trawling old/major Git repos, and then we have a Jenkins-powered server that does functional tests on a pile of major projects (Python, Ruby, PyPy, Vim, Git and Mercurial themselves, some other stuff I'm spacing) to make sure that what goes in also comes out. The test suite is kept tiny enough we can sanely run it locally; the functional test suite takes much longer, so it just runs in batches every hour or so, I believe. I'll double-check with QA and update this if I've got that off in any meaningful sense.
Super stoked to hear about those upcoming posts. What is the guiding strategy for dealing with these complexities? Hold on to everything and only present the relevant ones to the connecting client?
Joel's very own article on the Law of Leaky Abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...) comes to mind. Kiln Harmony might abstract away which VCS system you use, but I think in the real world you will just end up having to know both systems (or finally standardizing on one). Think of communication, for example:
- How do I do blah?
- Well, you type hg blah-blah
- What's hg?
- I fixed this bug on master
- Where?
- Oh, are you using mercurial? It's called a tip in your world
IMHO this stuff alone makes using two almost identical but different version control systems within a team a bad idea. Then there's that another layer that is supposed to work transparently, but when you have a problem you're never quite sure... is there a bug in hg? git? kiln?..
Really, just pick one system and use it. (hint - pick git :)
Plugins are hell. As a former contractor I came to loath hg because of them.
"Ohhh, you know hg, great! Lets get started, so our workflow consists of ... 35 minute explanation of 28 community plugins and 4 custom corporate ones".
If it really was that simple, mastering a new VCS would take 5 minutes. But it isn't.
If you need to branch, you also need to know how to merge. Then you'll need to know how to resolve conflicts. You probably need to know what branches are there and how to diff them. And since you know how to check in, it's just a matter of time before you'll need to know how to revert. That's just you alone - once you collaborate with someone else, you'll need to learn how to share code, push, pull, remote branches... There's a reason why your VCS has more than four commands.
There are things you have to really care about and things that just have to be good enough. Version control is in the latter.
Just use Git. Or Mercurial. It doesn't matter. They are just about the same and the minor improvement you might get from one over the other is just not worth the effort of thinking about it. Now go do something more useful with the cycles you save.
In summary: anyone who has a pressing need for this product has their priorities wrong.
I don't have a horse in this race, but I feel like this ship has sailed. Personally, I don't like jQuery's API, but it has become so popular that it's the honorary JavaScript standard library. I'd be hesitant to start a new project using MooTools, knowing that most people I might hire or most frameworks I might want to incorporate later probably know/expect jQuery.
I feel like GitHub has done the same thing for Git. Mercurial is in Python, which in theory would make it easier for me to hack on if I ever needed to, but the community has settled on Git. I think the fact that Atlassian bought BitBucket, which was a boutique version control tool for Pythonistas, and the very first thing they did was add Git support and position it as an alternative to GitHub speaks volumes to this.
I know that there are people who prefer Mercurial, and I'm glad they have that choice, but I feel like choosing Mercurial over Git for a new project is swimming upstream without any real benefit.
There are a fair few people who choose bitbucket over github because the pricing structure is saner if you have a load of repos and a fixed (or predictable) number of staff who require access.
And since last year, you can choose Bitbucket and still use git 100% of the time.
THAT seems to me what Fog Creek is doing here -- realizing, shit, we picked wrong, but now we have all these users, how can we take a mulligan and pick git?
And they did it. So like somebody else here said, what they've done is change the answer to "Does it work with git?" from no to yes.
(Note I am also not saying that anybody choosing hg over git for their own development 'chose wrong'. But if you are trying to do business by selling people a mainstream DVCS service, hg isn't the best choice you could make.)
I'd just like to add that one thing I like that bitbucket offers over github is free private git repositories (if you don't mind being limited to 5 users). Not compelling for everyone, but it's nice to have the option.
Then she should use the obscure dvcs and use extensions/plugins if necessary to communicate with remote git and mercurial repos. A dev can't expect the outside world to cater to some relatively obscure choice of dvcs.
You might as well ask, "What if a developer is most productive using cvs?"
A change resulting in a short-term loss of comfort and productivity can lead to a long-term increase in productivity and equal comfort, but everyone who's used to something likes to think it's a global optimum instead of merely a local optimum. There is also benefit in using the same tools that other developers use when collaborating on a project.
Well, even among developers there's clustering. So not many developers are "most productive" using those DVCS. Probably because they have never heard of them or never used them, but it doesn't really matter right now.
If your name is Git, you're number 1 in the DVCS space. If your name is Mercurial, you're a distant 2. If your name is neither of them, only a few people have ever heard of you. Sort of like this: http://xkcd.com/435/
Ugh, I really hate how Bazaar is considered "obscure". I really think it's the most usable of the three big VCSes, and even hg could learn a bit from it. git's porcelain is an asylum escapee, it's completely insane.
> In summary: anyone who has a pressing need for this product has their priorities wrong.
That's just silly. Both Git and Mercurial take a fair amount of effort to learn to use fluently, and if someone is already an expert in one, they are likely to feel that being forced to learn something else that's completely different and yet exactly the same will take a lot of useless effort and distract them from more important things. Something that solves this problem and lets programmers focus on their real work is certainly useful!
I agree, I use git and have never tried mercurial but I doubt that it is so bad that I would seek to look for a way to continue to use git on a project that was already on mercurial (CVS might be different of course).
I imagine that understanding how this tool deals with whatever the idiosyncrasies are between the two systems would be higher friction in the long run than just reading the mercurial manual.
I was pretty disappointed when I installed the Windows kiln client just now and it dumped me into an unintuitive (customized?) TortioseHg Workbench GUI without any sort of direction of where to start. The link of the webpage to hg init, didn't help much because it was seemingly all about the command line interface.
Most of the tools out there in DCVS land seem to have as a prerequisite that you already know how to do it the hard way. If I've already climbed the learning curve for the hard, but powerful, way I'm probably just going to keep doing it that way.
The opportunity is for a tool that makes easy things easy. I signed up for the SourceTree Windows beta, hopefully that's it.
> This means that you never have to decide whether you want to use Git or Mercurial. Religious war: averted.
I think the religious war is already over, and Git won. The only time I hear about Mercurial is when Fog Creek talks about it; approximately everyone else is on Github.
(Update: For the record, I don't think Git winning this war was due to it being technically superior in any significant way -- but neither is Mercurial superior enough to make it worth teaching everyone how to use two different DVCSes. Git was good enough, and then it won the mindshare war, and now it's the standard.)
Git is certainly much more widely used in general for open-source, but there are plenty of major projects that are on Mercurial. Python, Vim, Mozilla, dovecot, Go, NetBeans, and mutt all come to mind really quickly. Something like Kiln Harmony means that you, as a Git user, no longer need to care that these projects are on Mercurial. And conversely, if they want to use a project that's in Git, they can, from the security of their Mercurial workflow.
The Mercurial support is very welcome for those of us who found it a battle getting our employers to switch from SVN to Mercurial and don't want to go through that again. Unlike the transition from SVN to a DVCS, a transition from Mercurial to Git would not really be of any great advantage. And our code is not open source so it doesn't make much sense switching just because in the wider world Mercurial is out of fashion.
I don't know if this helps you, but try telling them that they can leave the 'distributed' part for later. At my company we still have a 'central' repository. We'd really need to know more about your companies objections to DVCS to give advice.
I personally just started using mercurial local-only alongside svn, and as new projects started I would try to make mercurial the default repo for that project. This worked well for me, but my company is pretty laid-back about these kinds of things.
The best application of "embrace, extend, extinguish" I ever saw:
1) Replicate SVN workflow in GIT. SVNs features/limitations are a tiny subset of GIT so this works well. Not too proud to admit the first day had a handwritten translation cheatsheet.
2) Stop worrying about branching and merging being evil, last year rolled out git flow which mostly just formalized and standardized whats already being done, etc.
3) Shut down the old SVN infrastructure after its unused long enough.
I think for an enterprise, the D part of DVCS isn't much of a selling point. What is a good selling point is all of the other stuff that makes Git/HG awesome, like easy branching and merging. There's also Github Enterprise, which if you can pay for it is really fantastic.
The D can be a selling point. Some things D enables:
Working offline is completely transparent. If your employees are on an airplane, or if the wifi at the conference they are at is overloaded, or if the central repository goes down for some reason, people can continue to work normally.
Code review based on asking for permission, not forgiveness. While the UI is a bit horrid, gerrit has been a huge win for us when it comes to code reviewing changes before they are out "in the public". When code review happens after something gets committed to the main repo, it's far to easy for issues to get forgotten about and never addressed. (Of course, Github pull requests have a better UI than Gerrit, but you might have reasons not to want to entrust your code to Github. And, also of course, this isn't strictly something that can only be done in a distributed VCS, but it seems to be a lot more natural in that context.)
> I think the religious war is already over, and Git won.
And this is how Fog Creek adapts to that reality without alienating their existing customers. They were headed directly at a tar pit. This this is the step sideways which will allow them to continue moving forward.
I've been doing Google searches every now and then to try to assess the relative popularity of Git vs Mercurial. Two years ago it seemed to be 2:1 in favor of Git. A year ago it seemed to be 3:1 in favor of Git. Now I think it is about 5:1 in favor of Git. Here are my most recent Google hit counts:
git 208M
git revision 6M
git version 56M
git control 19M
mercurial 29.5M
mercurial revision 1M
mercurial version 7M
mercurial control 6M
Google trends of "git repository" vs "mercurial repository":
hg revision 5M
hg version 55.5M
hg control 63.M
hg OR mercurial revision 6M
hg OR mercurial version 70.5M
hg OR mercurial control 74M
The decline in popularity of "mercurial" vs "git" seems real, but I agree that "mercurial" searches may be under-reporting the popularity of Mercurial. The top hits for "hg -mercurial revision" have nothing to do with Mercurial, tho.
I'm seeing exactly the opposite. There's an argument to made to the effect that `hg` picks up a lot of things that have nothing to do with source control, but that's still a big difference.
That's search volume. Parent was talking about search hits. I'd believe that search volume is more important, but I stand by my point in the context of this thread.
Joel Spolsky's live demo of FogBugz & Kiln is the single best product demo I've ever seen. Ever. It's so good, anyone doing demos should watch it, just because.
I don't know if I care about evidence based estimating. And I'm pretty sure FogBugz is overkill for my team's needs. And I'd rather eat glass that do anything Windows.
But hot damn the (apparent) integration and workflow of these two products are quite polished. Very well thought out and very well executed.
I have a hard time believing anything is the 'future' of version control if it doesn't have a free, public open-source plan. GitHub and BitBucket have huge amounts of inertia, and hence dominate in mindshare.
Github's workflow, features and terminology are focused on open source projects and those projects tend to work in a specific way. Kiln is focused on providing features that fit better inside a business environment. For example, the idea of a pull request is a bit foreign in a business environment. Internally, almost all the code written eventually gets shipped, so the social interaction around pull requests doesn't fit exactly right.
How is the "social interaction around pull requests" not just a synonym for "code review?"
Now, I recognize that much code written in a "business environment" does indeed ship without review. I just don't think that's a good thing.
If what you're saying is that you've yanked code review tools because customers don't want them, my only reply is that I'm afraid I'm unlikely to be a customer.
No, we have code reviews instead of pull requests, which as you point out is mostly terminology. But that terminology is indicative of assumptions that are baked into how the software operates. The assumptions and workflow of Kiln assumes you are using it inside of a business. I just gave one superficial example of a larger point I was trying to make about our intentions vs. people creating open source solutions and how that translates into defaults/workflows/usability of the software in different areas.
Give us some more examples, please. The pull requests vs. code reviews distinction is unconvincing.
I'd love to find a DVCS SaaS that provides better integration with the business software engineering workflow, and a UI that doesn't suck. So far I don't see a whole lot of that going on in kiln+fogbugz.
In my particular little enterprisey world, pull requests are something myself and some of the other bleeding-edge guys would like to work up for a workflow over a traditional branch and merge workflow. We think it's better for what we do. YMMV.
I read your blog-post and went "oh yeah - kiln. I wonder how they compare to BitBucket and GitHub. Let's look at the pricing page. Oh, the smallest plan is $25/mo. Guess I'll keep my one-person startup on BitBucket then."
If you want to compete with BitBucket and GitHub, you guys might want to feature the startup plan more prominently on your pricing page. The mention of it is so far below the fold that I didn't even see it on my tablet.
(If you are primarily focused on enterprise, that's cool too. I just feel like the mindshare for DVCS is trapped in the more community-centric players.)
Since everybody is always repeating it and one can take Git being the "winner" of the DVCS "war" as a fact, I just have to ask: why tf did Git win at this?
...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages (yeah, they make sense after you dive into the docs to search for the thing mentioned in the message or you google for it, but that's not how it should be) ...and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly nightmarish if you stop to think about it instead if just using it on auto-pilot
> and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho
Actually, I think you are perfectly wrong about that "sin". You just hit upon the exact reason why Git is good.
Git's point is that the data model is the tool. There is no abstraction (or at least very few), because it would only serve to camouflage what is important about it. It's just a data model and tools to manipulate it.
The way to explain Git is to start with the database: blobs, commits, references, and so on. The neat thing is that the way Git implements version control -- that is, linear version control (there are exceptions, like Darcs) -- is how version control must necessarily work.
In other words, if you understand Git, you understand how version control, and vice versa.
Of course you can have a VCS that is a completely black box. But even a black box needs a sort of public data model that the user understands ("files", "versions", "branches"), and I think Git's transparent, open-engine-approach is better than any other approach so far. For one, it makes it really extensible.
(I used to be a Darcs user, which requires that you become a quantum phycisist to understand its data model. I loved Darcs, but it meant that it broke, and it often did, it was almost impossible to fix the problem by hand.)
Now, I absolutely admit that Git's UI is terrible. It's geared towards hard-core developers who work on things like the Linux kernel. There little middle ground between the easy and the hard, and the learning curve is steep. But this is the fault of the command-line tools, and my thesis applies regardless of the UI.
Git has gotten better over the years. Just the fact that a newly created branch now has a default origin branch (so you don't have to set up the two .gitconfig keys you would need manually) is an amazing usability improvement that should have existed from the start.
I have used hg for about four years now and have basically transitioned over to git. It's hard to explain why, exactly. Yes, network effect, but it's more: it's like git integrated deeply into the underlying model rather than trying to abstract over the model.
I would call myself a power user - I am the clearcase->hg transition guy in what I do, I've designed/maintained an enterprise hg extension (guestrepos, look 'em up, they are amazing), use mq, etc. But I think that the fundamental win for git is that they don't abstract, and this allows clearer understanding of what is happening when things go pear-shaped.
But, that's my opinion. I use both on a daily basis.
TortoiseHg developer here (i.e. I'm probably biased, take my comments with a grain of salt, yada, yada, yada...).
We discussed this a bit on the last mercurial sprint.
In jest, someone said that a lot of git users have what they'd call a "Helsinki syndrome". Probably that is not very far from the mark.
I think that what git brings in functionality is good enough (specially compared to non DVCSs) to make people want to use it and put the effort to understand it. On the other hand it is hard enough to use that when people finally manage to wrap their heads around it they are so proud that they must tell everybody about it.
It is actually quite brilliant if you think about it: Make a SW that does something really well, better than most other similar tools, but wrap it in a horrible UI to keep your users on their toes and make them proud that they are able to use it! This starts an incredible self-congratulatory feedback effect which gives notoriety to your tool.
If you add to that the fact that git was created by one of the most famous hackers of all time, plus the creation of GitHub, and then you get the perfect storm to make git the open-source tool of choice.
Mercurial on the other hand is just as useful (if not more) than git, but it is just not as hard to use. People use it, like it, but they do not need to feel proud about it. It is just easy. There is no need to talk about database details, reflogs, etc. There is no need to blog about it. It just works. This should be great and make mercurial the better tool but it has the perverse effect of not making it cool to talk about it. There is no challenge, there is no achievement in learning how to use mercurial. This makes it hard to get the same sort of buzz that you get from a tool such as git.
In my opinion it is a little surprising that such a knowledgeable bunch such as the Hacker News readers and the open source contributors in general are not able to evaluate both tools just in their technical merits and instead follow the buzz. Understandable, but surprising nonetheless.
> ...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages
If a tool makes you productive, you make the effort to look beyond its flaws.
I was thinking about the other day, and I disagree. The main beef I have with git is that it's NOT UNIXy enough. Instead of having one command for one thing, it has one command for several different things (eg, git checkout) which I find absolutely aggravating.
Why do developers love *nix systems? Git and unix have a lot of parallels, especially in that git tries to embrace the unix philosophy of having lots of little tools that work with each other instead of one monolithic binary.
I was giving a presentation few years ago when SVN vas still a king and hg and git were only emerging (I included bazaar too in that presentation). Even then I recommended to pick up git. I don't remeber giving any really solid reasons, it was more like a hunche, but now when you asked. I'd say git just does make sense at some deeper level.
Whe foundation is very sound you can fix bad UX later, but when foundation is no so good, you will suffer endlessly.
Wikipedia has an interesting table comparing the command names used by various version control systems. Unsurprisingly, git makes up new names and reuses other names in new contexts. :)
Interesting - I was trying to get this concept to work a few years ago after I got a live SVN/Mercurial translator working, but it was very hard due to all the differences they note in this post.
One thing they don't mention is "octopus merges" - Git allows a merge to have more than two parents, while Mercurial does not. I'm sure there are other tiny edge cases, too; I wonder how they handle those?
Perhaps more to the point, I'm concerned that this means you're stuck using the lowest common denominator of both systems - for example, no hg bigfiles stuff.
I'll be publishing a series of articles that dive into the nitty-gritty of how Harmony works in the coming days, so I don't want to answer every single "How do you?..." question in this thread, but since you're the first one:
Git octopus merges of N parents are exploded into N-1 commits, each of which has some Harmony-specific metadata in its changeset extras field. We then use this data both to reassemble the octopus merge, and to prevent you pushing a changeset that has one of the "fake" octopus merges as a parent.
This is likely to be a painless (if it works) transition mechanism for companies that chose mercurial and now want to follow git.
I respect fogcreek and avidly read everything Joel wrote at the turn of the century. But I had a years free kiln hosting that I must have used twice after setup and I just found GitHub so much cleaner and, well, it worked with git.
Being quiet for a year is not the sign of excellent planning and product management either - if they had this great plan 12 mths ago and knew it would take this long then go do it fine, but hire some oter guys to keep inching the rest of the product along - 12 mths is just dead. I am guessing they realised they had backed the wrong horse and tried to make a compatible product - when really just cloning GitHub and aiming at Joel's core sme market would work.
Edit
Should not be knocking the technical effort and work here - just the strategy...
I went from hg -> git in the last couple of years. I'd say they are "almost identical". The key difference is a slightly different mindset on merging and branching IMHO. It can be non-trivial for some of my more hard headed dev brethren to change their way of thinking once they've chosen a method and gotten in the correct mindset.
I went from using mercurial to git and I still have lots of respect for mercurial. I wouldn't mind the switch at all if I needed to work with a team who used mercurial, but personally I still just prefer git.
Yup, that's me in a nutshell. I used svk first and then moved on to mercurial.
Then I had to learn git. I like the model for lightweight branches in git (bookmarks in mercurial) but the step backwards in UI is still irritating. I'm used to it at this point but teaching it to others is a constant source of pain ("git checkout -t/-b"!)
Ugh, no, I fought my way through git first, and I didn't think hg was the same when I encountered it, I thought hg was nigh-unusable after I thrashed at it for a week.
I work for an agency that often picks up work from large agencies or in-house teams and most of the time I find myself using either Subversion or Mercurial. We use Mercurial for our own projects, but one client uses Git, which I use at home and prefer it to Mercurial.
It's a situation I imagine a lot of development agencies find themselves in.
The last company I worked at had a least a half dozen different dev teams working on more or less unrelated projects, all doing their own thing. While each team all used the same tools internally, the different teams used different tools and each team handled its own vcs hosting. I can imagine a company like that might want to get everybody on the same page, without forcing one team to give up their favorite tool.
I'm not aware of any, but I suppose this means you can use your preferred tools even if the rest of your team disagrees.
For my home projects, I used Mercurial for a year since I preferred its command-line tools to Git. When workable GUI tools for Git appeared (starting with Github for Windows), I migrated to Git.
Also, a small bravo to Fogcreek for using a screen grab from Windows. Windows is so uncool that we need some Windows screen shot affirmative action.
Is having to make a binary choice between Git or Mercurial, really that big a deal?
I just assumed that teams would make a consensual decision, stick to one and get on with it.
Seems like a great feat of engineering, but is it that wide a problem? (genuine question).
For business group A, I use RCS. For business group B, I use SVN. For my own personal stuff I use git.
No joke.
Mercurial, Perforce, Clearcase are also in use depending who you ask. I'm sure we have some CVS still in use somewhere, and I think Bazaar may be installed, though I don't know who uses it. Basically if it exists, we have it installed, and someone might be using it, somewhere among the order of 100k employees worldwide.
That would explain my naivete on the matter. I don't deal with corporate much at all.
I guess it makes sense for the corporate environment in that case then.
This is extremely impressive from a technical point of view, but I'm wondering if it's the wrong solution, given that arguments over a version control system are largely an organisational issue? Surely a better approach would be for everyone involved to negotiate and come to an agreement on the tool to be used, or have it mandated from on high.
(Please wait a couple of mins before replying while I don my flame-retardant suit ;)
How does this compare to ESR's reposurgeon tool? [1] I understand Kiln Harmony is a website, not a command-line tool, but it seems like they must have had to solve many of the same issues.
That's pretty radically different. A closer analog might be hg-git, but the moment you say that you want the entire process to cleanly round-trip, you have to preserve all kinds of weird and corrupt data that the modern incarnations of the tools don't let you create (for good reason). There's also a lot of internal metadata, especially in Mercurial, where there are multiple valid ways to store a given concept, but only one will yield the right SHA for a given changeset. Not only did no existing tool try to handle these issues; they were all built in ways that would've made such preservation impossible. That's why we had to write our own from scratch.
I suspect it'll be an uphill struggle. Like many pointed out, Git is good enough, it's free (as in beer as well as in speech) and ubiquitous. Where it's not is the domain of proprietary, hideously expensive and deeply entrenched (sometimes bundled with IDEs that run on only one OS) solutions their users hate, but corporate IT mandates the use nevertheless because it was not a user-driven decision.
This is crucial: it; s hard to sell software ir services to these clients by providing something great. You sell by making the CEO feel capable of making decisions like what DVCS their IT department should use.
I like the concept, but I have two objections to it. One, as pointed out by others, I'm highly skeptical of some of those edge cases. They mention a few of them at the end of that article, but they largely gloss them over saying they're dealt with automatically. My other objection is with Kiln itself. Not open source, not cross-platform, and even on Windows it seems to have strange requirements (like you can't run it on the domain controller). Sorry, any service that requires Windows is a automatic fail so far as I'm concerned.
Are you talking about the Kiln servers, or issues with client software? The servers are hosted, so you don't need to worry about any requirements or cross platform issues.
The servers. I was looking around on the site to try to find more info about Kiln, and one of the FAQs was the system requirements for the server (for companies that want to host their own Kiln instances I'd assume). With git or Mercurial I can spin up my own host in a variety of ways, or if I want something slicker I could host my own instance of github (not sure about BitBucket, but I suspect it likewise can be self-hosted). With Kiln if I wanted to go a similar route I need to have a Windows server with IIS and a variety of other dependencies.
Ah, that's old documentation. We host Kiln on our servers now, so we don't sell on premise versions that you'd have to install which makes this a bit moot. But if we do start to do that again, you would be able to spin them up the same way you'd spin up GitHub enterprise, with a VM: https://enterprise.github.com/faq
Considering my company bought into self hosted FogBugz & Kiln early last month I'm concerned that we need to start looking elsewhere now as we aren't going to see updates from here on...
It's quite sad as our company specifically can't hold source code and other information in an external environment (especially across borders) due to the nature of our client base.
When have you stopped that and what happened to the existing customers? Did you ever announce that? I have noticed that FogBugz is now in very fine print in the version for your own servers, so it looks like you want to kill that off, soon. How long do I have until I have to find something else for bugs? I'm very concerned about this!
Of course you are not killing off FogBugz! But what about the version for your own server? Is that going away or staying? I read your message like it's going away, otherwise you could have written that FogBugz will still be available for your own server!
I was really sad to hear this when our company evaluated Kiln a couple months ago. Off-site hosting is not an option for our company, so we had to go with another product despite strong user preferences for Kiln and FogBugz.
I hope a "firewall" install returns as an option someday, at which point we would eagerly reevaluate our choice...
I'm surprised that it can't be self-hosted, since the product is explicitly directed at enterprise. Any company with a large or important codebase is likely to want completely secure control over their VCS. Anecdotally, at least, external hosting would never fly at my company.
I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So I ran over and said "Stop! don't do it!" "Why shouldn't I?" he said. I said, "Well, there's so much to live for!" He said, "Like what?" I said, "Well...are you religious or atheist?" He said, "Religious." I said, "Me too! Are you christian or buddhist?" He said, "Christian." I said, "Me too! Are you catholic or protestant?" He said, "Protestant." I said, "Me too! Are you episcopalian or baptist?" He said, "Baptist!" I said,"Wow! Me too! Are you baptist church of god or baptist church of the lord?" He said, "Baptist church of god!" I said, "Me too! Are you original baptist church of god, or are you reformed baptist church of god?" He said,"Reformed Baptist church of god!" I said, "Me too! Are you reformed baptist church of god, reformation of 1879, or reformed baptist church of god, reformation of 1915?" He said, "Reformed baptist church of god, reformation of 1915!" I said, "Die, heretic scum", and pushed him off.
Yes, but it's extremely silly since most hg users are also git users, not of their own choosing, since many popular OSS projects are hosted at GitHub.
There's a "winner take all" rally amoung certain git fans, whom have lost their sense of history, equating popularity with quality. Ironic, since the creater of git should have just switched to Windows in the '90s, because it "won already".
Kiln Harmony won't save as much money and angst as a DVCS that automatically converts tabs to spaces and back, based on personal settings, or one that changes bracket code formatting, but it's a start.
It's not too hard to write a Mercurial extension to do that kind of thing. Copying the code for the EOL extension (http://mercurial.selenic.com/wiki/EolExtension) and modifying it would be a good start.
If being fully git/hg interoperable was holding back sales, I can understand their year-long investment. What is holding back me buying into FogCreek's products is tightly integrated Trello-Kiln-FogBugz. Hope you get to this soon.
oh, and for the love of all of us doing dev in China, can some of these SaaS's please put a server over here so we can reliably use your products. Trello's single page app works pretty well from China. Most don't. I'm stuck with redmine and other things I can self-host.
It seems as though having members of the same team mixing up mercurial and git. They have their own language and idioms. Think about trying to work together in such an environment. For some tools it's simply better for the team to homogenize than stay diverse. We're not talking about a text editor.
Since when is the version to be installed on our own servers unavailable? I always wanted to buy it once I have the svn conversion problems figured out. How long do existing FogBugz users have until the non-hosted version is removed from the market, too and how long are we able to get updates?
I could be wrong, but I don't think the git/mercurial integration is the big point of Kiln.
Rather, harmony seems like an interesting side effect generated when Fog Creek built some swank tools for mercurial-based corporate developers, and git won the war while they were doing so.
Most of the value I see in Kiln is in the activity filters, the notifications, the code review tools, the ACLs, and FogBugz integration. Git/Mercurial interoperability is just a cute feature.
As someone who said exactly that and pays for FogBugz, but uses GitHub: now I read about what they did and think "why would they do that? It's a horribly complicated technical problem, I can't be sure they got it right, I'll stick to GitHub".
I absolutely agree that Fog Creek needed to support Git, but I don't think Harmony sells meaningfully more than Git-only + hg-only would've. That's why I refer to it as a cute feature.
Fog Creek's emphasis on how they achieved git support steered the discussion to be about the value of git/hg interoperability, rather than the value of Kiln for corporate developers. And it seems like the consensus is that git/hg interoperability is, at best, a nice-to-have.
It's really tiring to see what the Spolsky and Atwood offsprings are coming up with...
It's nearly always the same "idea": try to prevent users from having opinions and individuality.
Atwood's discourse.org was supposed to be the "next generation of forums because the current forum aren't civilized enough": people supposedly aren't "civilized" enough to be able to have their own forums. No, one should use a forum engine made for and by control freaks that shall enforce civilized discourses.
Now this Kiln Harmony thing is supposed to "end the flamewar" between git/hg: people are allowed to have their own preferences anymore. Everybody is going to "win" because they'd be using the system created by and for control freaks.
And StackOverflow is preventing individuality and allowing a few control freaks to reign king and decided what kind of thoughts people are allowed to have.
In other words these guys think they've identified a "problem": individuality and personal opinions. And they think they have a "solution": control.
Interestingly enough when I just entered discourse.org to see how that one is catching up it seems to be the better ranked in... The republic of China! (no kidding here).
Which is normal: control freaks are going to love software restricting choices and individuality.
But I love my freedom. I love individuality and I think everyone should be free, including free to chose and say why they prefer hg over git or vice-versa.
So their "solutions" (discourse.org, Kiln Harmony) aren't going to be the "next gen anything" because there are too many individuals who value their individuality.
Oh and, and even though I was an early hg adopter, I have to admit that git (and github) won big times.
It's as if they realized they didn't bet on the correct horse (inherent qualities aside, I'm purely talking about market share here) and that hence they've been "owned" by people pointing out to them that git / github was winning. It's an argument they couldn't win: there's no way hg is as succesful as Git (once again: I haven't switched yet to git... I'm a long time hg user but I have to admit defeat here). So because they couldn't admit that they were wrong they decided to create an utterly complicated solution: "To put an end to the flamewar".
I really hate the Spolsky and Atwood of this world because to me they love dictatorship.
I'm for freedom and individuality, not for control freaks trying to decide how people should think / talk / code / use DVCSes etc.
And thankfully there are way enough people like me so that these control freaks are never going to win.
Even SO is going to be replaced the day something less bent on dictatorship comes along.
