|
6
|
|
|
UPDATE: Kiln Harmony now supports both Git and Mercurial, natively, with the same repositories! Read more here.
When you ask why Kiln chose Mercurial, there's really two questions:
- Why is Kiln based around a DVCS?
- Why did Kiln choose Mercurial, specifically?
Why is Kiln based around a DVCS?
Because DVCSes provide real branching. As you know, managing branches in Subversion, CVS, and similar tools inevitably proves to be an extremely frustrating experience. Because Subversion before 1.5 does not record merge history at all, and even the most recent versions cannot use that metadata constructively, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs. Instead, what inevitably ends up happening is you end up with developers always developing in trunk, and, on rare occasion, making "branches" that are little more than snapshots of your point releases.
All of the modern, DAG-based DVCSes, including Git, Mercurial, and Bazaar, know exactly when and where you last merged. They have special "merge" objects in their histories, and even bring over the history of everything you're merging in. As a result, they can trivially handle complicated merges automatically that cause Subversion and similar tools to vomit, and you yourself can trivially see, at any point, what you have and have no merged between branches.
And why does that matter? Because real software shops have to maintain several versions of a product simultaneously. Just because you shipped version 2.0 doesn't (usually) mean that you can quit providing support for version 1.0. In a classic VCS, such as Subversion, you've got to make separate commits to the bug fix on every branch you care about. There won't be any direct indication that it's the same fix in both versions, no way to track what fixes got merged and when. Verifying that any given feature actually got in becomes complicated.
In a DVCS, that's not true. Merging goes easy, because the tool knows what you want to merge. Verifying that the bug fixes to 1.0 ended up in 2.0 is as easy as making sure that the commits from 1.0 appear in 2.0. Parallel development suddenly becomes really easy.
This is the killer feature that we believe make all DVCSes awesome, and a huge step forwards from tools like Subversion and CVS. And it's why Fog Creek has decided to place itself solidly in the DVCS proponent camp with Kiln.
Why did Kiln choose Mercurial over other DVCSes, such as Git?
We'll be honest: we love Git. It's ridiculously fast, the Ruby community loves it, it's powerful enough to handle massive projects like the Linux kernel, and it has a really cool community built up around sites like GitHub, which is kind of like a Facebook for developers.
But we also like Mercurial. It's nearly as fast as Git, it's really extensible, it has really great Linux and Windows GUIs, it also manages really big projects like Firefox, Python, Java's OpenJDK, and OpenSolaris, and it has a really awesome community of its own through Google Code and Bitbucket.
In fact, both Mercurial and Git are so close from a features perspective that we honestly don't understand the bickering. They're both DAG-based DVCSes. They both do kickass merges, they both have the same geek features[1]features1, they both have big community support (such as Linux, Ruby, and X for Git, or Python, Java, and Google for Mercurial), they're both ridiculously fast. Really, it comes down to personal preference.
So, really, both tools are absolutely awesome. In fact, we're pretty convinced that if you like one, you'll probably like the other--and that if you're using a tool like Subversion, using either would be a tremendous improvement. But, at the end of the day, we had to pick one to base Kiln on, at least for the initial release, and after a lot of looking around, we think that Mercurial's a bit easier-to-use for people new to DVCSes, without sacrificing any of the power of Git.
The important thing, from where we sit, is to help usher in the DVCS revolution. The exact tool people use doesn't really matter so much. We personally have a slight preference for Mercurial, others have a slight preference for Git. Focus on DVCSes vs. the monolithic tools; the rest isn't really that relevant.
[1]
1 Those geek features include things like rebasing (git rebase and hg rebase), partial commits (Git index and hg record), history editing (git rebase --interactive and Mercurial's ridiculously powerful MQ facility), signed patches, and so on. Seriously, there's equivalents for basically everything in one tool and the other.
|
|
|
|
|
5
|
|
edited Sep 2 2010 at 18:08 |
When you ask why Kiln chose Mercurial, there's really two questions:
- Why is Kiln based around a DVCS?
- Why did Kiln choose Mercurial, specifically?
Why is Kiln based around a DVCS?
Because DVCSes provide real branching. As you know, managing branches in Subversion, CVS, and similar tools inevitably proves to be an extremely frustrating experience. Because Subversion before 1.5 does not record merge history at all, and even the most recent versions cannot use that metadata constructively, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs. Instead, what inevitably ends up happening is you end up with developers always developing in trunk, and, on rare occasion, making "branches" that are little more than snapshots of your point releases.
All of the modern, DAG-based DVCSes, including Git, Mercurial, and Bazaar, know exactly when and where you last merged. They have special "merge" objects in their histories, and even bring over the history of everything you're merging in. As a result, they can trivially handle complicated merges automatically that cause Subversion and similar tools to vomit, and you yourself can trivially see, at any point, what you have and have no merged between branches.
And why does that matter? Because real software shops have to maintain several versions of a product simultaneously. Just because you shipped version 2.0 doesn't (usually) mean that you can quit providing support for version 1.0. In a classic VCS, such as Subversion, you've got to make separate commits to the bug fix on every branch you care about. There won't be any direct indication that it's the same fix in both versions, no way to track what fixes got merged and when. Verifying that any given feature actually got in becomes complicated.
In a DVCS, that's not true. Merging goes easy, because the tool knows what you want to merge. Verifying that the bug fixes to 1.0 ended up in 2.0 is as easy as making sure that the commits from 1.0 appear in 2.0. Parallel development suddenly becomes really easy.
This is the killer feature that we believe make all DVCSes awesome, and a huge step forwards from tools like Subversion and CVS. And it's why Fog Creek has decided to place itself solidly in the DVCS proponent camp with Kiln.
Why did Kiln choose Mercurial over other DVCSes, such as Git?
We'll be honest: we love Git. It's ridiculously fast, the Ruby community loves it, it's powerful enough to handle massive projects like the Linux kernel, and it has a really cool community built up around sites like GitHub, which is kind of like a Facebook for developers.
But we also like Mercurial. It's nearly as fast as Git, it's really extensible, it has really great Linux and Windows GUIs, it also manages really big projects like Firefox, Python, Java's OpenJDK, and JavaOpenSolaris, and it has a really awesome community of its own through Google Code and Bitbucket.
In fact, both Mercurial and Git are so close from a features perspective that we honestly don't understand the bickering. They're both DAG-based DVCSes. They both do kickass merges, they both have the same geek features[1], they both have big community support (such as Linux, Ruby, and X for Git, or Python, Java, and Google for Mercurial), they're both ridiculously fast. Really, it comes down to personal preference.
So, really, both tools are absolutely awesome. In fact, we're pretty convinced that if you like one, you'll probably like the other--and that if you're using a tool like Subversion, using either would be a tremendous improvement. But, at the end of the day, we had to pick one to base Kiln on, at least for the initial release, and after a lot of looking around, we think that Mercurial's a bit easier-to-use for people new to DVCSes, without sacrificing any of the power of Git.
The important thing, from where we sit, is to help usher in the DVCS revolution. The exact tool people use doesn't really matter so much. We personally have a slight preference for Mercurial, others have a slight preference for Git. Focus on DVCSes vs. the monolithic tools; the rest isn't really that relevant.
[1] Those geek features include things like rebasing (git rebase and hg rebase), partial commits (Git index and hg record), history editing (git rebase --interactive and Mercurial's ridiculously powerful MQ facility), signed patches, and so on. Seriously, there's equivalents for basically everything in one tool and the other.
|
|
|
|
|
4
|
|
edited Feb 9 2010 at 20:41 |
When you ask why Kiln chose Mercurial, there's really two questions:
- Why is Kiln based around a DVCS?
- Why did Kiln choose Mercurial, specifically?
Why is Kiln based around a DVCS?
Because DVCSes provide real branching. As you know, managing branches in Subversion, CVS, and similar tools inevitably proves to be an extremely frustrating experience. Because Subversion before 1.5 does not record merge history at all, and even the most recent versions cannot use that metadata constructively, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs. Instead, what inevitably ends up happening is you end up with developers always developing in trunk, and, on rare occasion, making "branches" that are little more than snapshots of your point releases.
All of the modern, DAG-based DVCSes, including Git, Mercurial, and Bazaar, know exactly when and where you last merged. They have special "merge" objects in their histories, and even bring over the history of everything you're merging in. As a result, they can trivially handle complicated merges automatically that cause Subversion and similar tools to vomit, and you yourself can trivially see, at any point, what you have and have no merged between branches.
And why does that matter? Because real software shops have to maintain several versions of a product simultaneously. Just because you shipped version 2.0 doesn't (usually) mean that you can quit providing support for version 1.0. In a classic VCS, such as Subversion, you've got to make separate commits to the bug fix on every branch you care about. There won't be any direct indication that it's the same fix in both versions, no way to track what fixes got merged and when. Verifying that any given feature actually got in becomes complicated.
In a DVCS, that's not true. Merging goes easy, because the tool knows what you want to merge. Verifying that the bug fixes to 1.0 ended up in 2.0 is as easy as making sure that the commits from 1.0 appear in 2.0. Parallel development suddenly becomes really easy.
This is the killer feature that we believe make all DVCSes awesome, and a huge step forwards from tools like Subversion and CVS. And it's why Fog Creek has decided to place itself solidly in the DVCS proponent camp with Kiln.
Why did Kiln choose Mercurial over other DVCSes, such as Git?
We'll be honest: we love Git. Git is awesome. It's ridiculously fast, it's heavily used in the Ruby community loves it, it's powerful enough to handle massive projects like the Linux kernel, it runs just about everywhere, and it has a really cool community built up around sites like GitHub, which is kind of like a Facebook for developers.
But we also like Mercurial. It's nearly as fast as Git, it's really extensible, it has really great Linux and Windows GUIs, it also manages really big projects like Firefox and Java, and it has a really awesome community of its own through Google Code and Bitbucket.
In fact, both Mercurial and Git are so close from a features perspective that we honestly don't understand the bickering. They're both DAG-based DVCSes. They both do kickass merges, they both have the same geek features[1], they both have big community support (such as Linux, Ruby, and X for Git, or Python, Java, and Google for Mercurial), they're both ridiculously fast. Really, it comes down to personal preference.
So, really, both tools are absolutely awesome. In fact, we're pretty convinced that if you like one, you'll probably like the other--and that if you're using a tool like Subversion, using either would be a tremendous improvement. But, at the end of the day, we had to pick one to base Kiln on, at least for the initial release, and after a lot of looking around, we think that Mercurial's a bit easier-to-use for people new to DVCSes, without sacrificing any of the power of Git.
The important thing, from where we sit, is to help usher in the DVCS revolution. The exact tool people use doesn't really matter so much. We personally have a slight preference for Mercurial, others have a slight preference for Git. Focus on DVCSes vs. the monolithic tools; the rest isn't really that relevant.
[1] Those geek features include things like rebasing (git rebase and hg rebase), partial commits (Git index and hg record), history editing (git rebase --interactive and Mercurial's ridiculously powerful MQ facility), signed patches, and so on. Seriously, there's equivalents for basically everything in one tool and the other.
|
|
|
|
3
|
|
edited Feb 9 2010 at 18:56 |
There are many reasons that we have chosen When you ask why Kiln chose Mercurial. Here are the ones that I personally think are most important, there's really two questions: It provides Why is Kiln based around a DVCS?Why did Kiln choose Mercurial, specifically?Why is Kiln based around a DVCS?Because DVCSes provide real branching. As you know, managing branches in Subversionbranching is incredibly poor, CVS, and similar tools inevitably proves to be an extremely frustrating experience. Because Subversion before 1.5 does not record merge history at all, and no version of Subversion can even the most recent versions cannot use that information in a constructive waymetadata constructively, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branchesin Subversion, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs. MercurialInstead, like other what inevitably ends up happening is you end up with developers always developing in trunk, and, on rare occasion, making "branches" that are little more than snapshots of your point releases. All of the modern, DAG-based DVCSes, does including Git, Mercurial, and Bazaar, know exactly when and where it you last merged. They have special "merge" objects in their histories, and even bring over the history of everything you're merging in. As a result, it they can trivially handle complicated merges automatically that cause Subversion and similar tools to vomit. Suddenly, actively maintaining branchesand you yourself can trivially see, one per productat any point, what you have and ensuring that all bug fixes end up in all relevant have no merged between brancheswithout manually porting patches, becomes downright trivial. It's easy And why does that matter? Because real software shops have to use. Mercurial, taking the exact opposite maintain several versions of Git, uses a lot of the same commands product simultaneously. Just because you already know from shipped version 2.0 doesn't (usually) mean that you can quit providing support for version 1.0. In a classic VCS, such as Subversion—and, if you're working solo, even operates you've got to make separate commits to the bug fix on every branch you care about. There won't be any direct indication that it's the same fix in both versions, no way . Updating to a track what fixes got merged and when. Verifying that any given revision is hg upfeature actually got in becomes complicated.Reverting is hg revert In a DVCS, and resolving is hg resolvethat's not true. Merging goes easy, which works in a similar manner because the tool knows what you want to Subversionmerge. Committing Verifying that the bug fixes to 1.0 ended up in 2.0 is just hg commit, without dealing with an index or other weirdnessas easy as making sure that the commits from 1.0 appear in 2.0. Figuring out who did what on a file Parallel development suddenly becomes really easy. This is hg annotatethe killer feature that we believe make all DVCSes awesome, and a huge step forwards from tools like Subversion and CVS. And so on. It's much, much easier it's why Fog Creek has decided to pick up Mercurial than Git, place itself solidly in my opinion, allowing you to focus on the new functionality it provides (the DVCS aspectsproponent camp with Kiln. Why did Kiln choose Mercurial over other DVCSes, such as better branching and offline commits) than on how to perform the most basic of operations. (Watch a newbie try to figure out git commit or git checkout sometime. It can Git?We'll be quite elucidating.) Windows support is very goodhonest: we love Git. While Git's Windows support has been gradually improving, Mercurial's Windows support Git is very good, right nowawesome. TortoiseHg, a version of which we ship with KilnIt's ridiculously fast, provides integration with Explorerit's heavily used in the Ruby community, superb graphical tools it's powerful enough to view the handle massive projects like the state of your repository and its historyLinux kernel, and graphical configuration tools so you don't have to muck it runs just about with config files. It's fast. Despite being easy-to-useeverywhere, Mercurial and it has a really cool community built up around sites like GitHub, which is kind of like a Facebook for developers. But we also like Mercurial. It's nearly as fast as Git. Committing, moving around historyit's really extensible, viewing diffsit has really great Linux and Windows GUIs, all happen as fast as Gitand it has a really awesome community of its own through Google Code and Bitbucket.(Faster, in some cases: for example In fact, since both Mercurial explicitly tracks renames, pulling a given file's history runs much more quickly than in Git, and we believe Git are so close from experience that that's an operation a features perspective that users will need to do often.) It's powerfulwe honestly don't understand the bickering. All of They're both DAG-based DVCSes. They both do kickass merges, they both have the voodoo that Git users get really excited about—rebasing, history rewritingsame geek features[1], compacting commits—is available in Mercurial to those who want to use it. Unlike they both have big community support (such as Linux, Ruby, and X for Git, using these features is not encouragedor Python, Java, and their existence does not clutter up the basic workflowGoogle for Mercurial), they're both ridiculously fast. This means that users can steadily learn more about how to do complex things with MercurialReally, without getting bogged it comes down in arcana from day one. It's easily extensible. Adding additional functionality to Mercurial that behaves as if it were built-in functionality is wonderfully easypersonal preference. So, really, both tools are absolutely awesome. In Kilnfact, we're already starting to take advantage of pretty convinced that if you like one, providing tools you'll probably like hg svnblame and hg next to provide better help for those new to Mercurial. The Mercurial project itself ships many extensions the other--and that come up repeatedly in certain situations, such as working with patches over mailing lists, if you're using GPG to cryptographically endorse certain revisionsa tool like Subversion, and so onusing either would be a tremendous improvement. This means that it's very easy to tailor Mercurial to your specific needsBut, without having to modify Mercurial proper. There are lots at the end of other things I like about Mercurialthe day, including how easy it is we had to quickly share changes with colleagues (hg serve), figure out when a bug was introduced (hg bisect), find historical information (hg grep), and so pick one to base Kiln on, but the above are at least for the ones that I think are most important to meinitial release, and after a good collection lot of why we've chosen Mercurial looking around, we think that Mercurial's a bit easier-to-use for Kiln. The balance people new to DVCSes, without sacrificing any of the power , ease-of-useof Git. The important thing, and portabilityfrom where we sit, is largely unmatched by any other to help usher in the DVCS revolution. The exact tool people use doesn't really matter so much. We personally have a slight preference for Mercurial, others have a slight preference for Git. Focus on DVCSes vs. the monolithic tools; the rest isn't really that relevant.
|
|
|
|
|
2
|
|
edited Oct 24 2009 at 22:37 |
There are many reasons that we have chosen Mercurial. Here are the ones that I personally think are most important:
It provides real branching. As you know, Subversion branching is incredibly poor. Because Subversion before 1.5 does not record merge history at all, and no version of Subversion can use that information in a constructive way, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches in Subversion, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs.
Mercurial, like other DVCSes, does know exactly when and where it merged. As a result, it can trivially handle complicated merges automatically that cause Subversion to vomit. Suddenly, actively maintaining branches, one per product, and ensuring that all bug fixes end up in all relevant branches without manually porting patches, becomes downright trivial. It's easy to use. Mercurial, taking the exact opposite of Git, uses a lot of the same commands you already know from Subversion—and, if you're working solo, even operates the same way. Updating to a given revision is hg up. Reverting is hg revert, and resolving is hg resolve, which works in a similar manner to Subversion. Committing is just hg commit, without dealing with an index or other weirdness. Figuring out who did what on a file is hg annotate. And so on. It's much, much easier to pick up Mercurial than Git, in my opinion, allowing you to focus on the new functionality it provides (the DVCS aspects, such as better branching and offline commits) than on how to perform the most basic of operations. (Watch a newbie try to figure out git commit or git checkout sometime. It can be quite elucidating.) Windows support is very good. While Git's Windows support has been gradually improving, Mercurial's Windows support is very good, right now. TortoiseHg, a version of which we ship with Kiln, provides integration with Explorer, superb graphical tools to view the the state of your repository and its history, and graphical configuration tools so you don't have to muck about with config files. It's fast. Despite being easy-to-use, Mercurial is nearly as fast as Git. Committing, moving around history, viewing diffs, all happen as fast as Git. (Faster, in some cases: for example, since Mercurial explicitly tracks renames, pulling a given file's history runs much more quickly than in Git, and we believe from experience that that's an operation that users will need to do often.) It's powerful. All of the voodoo that Git users get really excited about—rebasing, history rewriting, compacting commits—is available in Mercurial to those who want to use it. Unlike Git, using these features is not encouraged, and their existence does not clutter up the basic workflow. This means that users can steadily learn more about how to do complex things with Mercurial, without getting bogged down in arcana from day one. It's easily extensible. Adding additional functionality to Mercurial that behaves as if it were built-in functionality is wonderfully easy. In Kiln, we're already starting to take advantage of that, providing tools like hg svnblame and hg next to provide better help for those new to Mercurial. The Mercurial project itself ships many extensions that come up repeatedly in certain situations, such as working with patches over mailing lists, using GPG to cryptographically endorse certain revisions, and so on. This means that it's very easy to tailor Mercurial to your specific needs, without having to modify Mercurial proper.
There are lots of other things I like about Mercurial, including how easy it is to quickly share changes with colleagues (hg serve), figure out when a bug was introduced (hg bisect), find historical information (hg grep), and so on, but the above are the ones that I think are most important to me, and a good collection of why we've chosen Mercurial for Kiln. The balance of power, ease-of-use, and portability, is largely unmatched by any other DVCS.
|
|
|
|
|
1
|
|
answered Oct 24 2009 at 19:17 |
There are many reasons that we have chosen Mercurial. Here are the ones that I personally think are most important:
It provides real branching. As you know, Subversion branching is incredibly poor. Because Subversion before 1.5 does not record merge history at all, and no version of Subversion can use that information in a constructive way, merging always ends up being an incredibly labor-intensive, error-filled process. As such, maintaining branches in Subversion, even if technically possible, ends up being such an incredible pain that developers generally try to avoid using branches at all costs.
Mercurial, like other DVCSes, does know exactly when and where it merged. As a result, it can trivially handle complicated merges automatically that cause Subversion to vomit. Suddenly, actively maintaining branches, one per product, and ensuring that all bug fixes end up in all relevant branches without manually porting patches, becomes downright trivial. It's easy to use. Mercurial, taking the exact opposite of Git, uses a lot of the same commands you already know from Subversion—and, if you're working solo, even operates the same way. Updating to a given revision is hg up. Reverting is hg revert, and resolving is hg resolve, which works in a similar manner to Subversion. Committing is just hg commit, without dealing with an index or other weirdness. Figuring out who did what on a file is hg annotate. And so on. It's much, much easier to pick up Mercurial than Git, in my opinion, allowing you to focus on the new functionality it provides (the DVCS aspects, such as better branching and offline commits) than on how to perform the most basic of operations. (Watch a newbie try to figure out git commit or git checkout sometime. It can be quite elucidating.) Windows support is very good. While Git's Windows support has been gradually improving, Mercurial's Windows support is very good, right now. TortoiseHg, a version of which we ship with Kiln, provides integration with Explorer, superb graphical tools to view the the state of your repository and its history, It's fast. Despite being easy-to-use, Mercurial is nearly as fast as Git. Committing, moving around history, viewing diffs, all happen as fast as Git. (Faster, in some cases: for example, since Mercurial explicitly tracks renames, pulling a given file's history runs much more quickly than in Git, and we believe from experience that that's an operation that users will need to do often.) It's powerful. All of the voodoo that Git users get really excited about—rebasing, history rewriting, compacting commits—is available in Mercurial to those who want to use it. Unlike Git, using these features is not encouraged, and their existence does not clutter up the basic workflow. This means that users can steadily learn more about how to do complex things with Mercurial, without getting bogged down in arcana from day one. It's easily extensible. Adding additional functionality to Mercurial that behaves as if it were built-in functionality is wonderfully easy. In Kiln, we're already starting to take advantage of that, providing tools like hg svnblame and hg next to provide better help for those new to Mercurial. The Mercurial project itself ships many extensions that come up repeatedly in certain situations, such as working with patches over mailing lists, using GPG to cryptographically endorse certain revisions, and so on. This means that it's very easy to tailor Mercurial to your specific needs, without having to modify Mercurial proper.
There are lots of other things I like about Mercurial, including how easy it is to quickly share changes with colleagues (hg serve), figure out when a bug was introduced (hg bisect), find historical information (hg grep), and so on, but the above are the ones that I think are most important to me, and a good collection of why we've chosen Mercurial for Kiln. The balance of power, ease-of-use, and portability, is largely unmatched by any other DVCS.
|
|
|
