101–110 of 165 posts
Earlier quoted context omitted.
I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.
More Guido and a couple of vocal people than CPython. I truly hope the switch wasn't the reason for Mackall to quit.
I did a project on integrating Mercurial with Mongo before, and I have to say being a Python developer I didn't have too much difficulty in figuring the right API, although the documentation is not so great. The code itself uses a lot of abbreviations which you have to really be patient to get familiar. The Mercurial model [1] is a pleasant read for a couple train ride (read it a few times I encourage). Others have d…
Earlier quoted context omitted.
> Ouch, yet another way in which running on Windows can lead to poor technical decisions. I've never heard from anyone that choosing/using Mercurial was a poor decision. Are you biased?
> I've never heard from anyone that choosing/using Mercurial was a poor decision. I liked hg too, but as the passage of time has indicated choosing it for one's project would have been a mistake, as git has effectively won.
Earlier quoted context omitted.
Have you ever tried out hg-git? It lets you interact with github repos using mercurial.
i've never tried. but i usually refrain from putting more technology than needed to reach my end goals. less is more, in this case. :P
Earlier quoted context omitted.
> As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Today, yes. Significant work went into getting Mercurial's internals up to parity with Git's, and conversely into getting Git's UI up to parity with Mercurial's.
Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010. Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot". Coming from a Mozilla-influenced, pre-GitHub-exp…
I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mea…
Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome. For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Fa…
Earlier quoted context omitted.
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm. rcs: revision control cvs: concurrent check outs svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this) git: decentralised version control To replace git, you need a new paradigm. I don't know what it is, and I think few people here would. Edit: to reiterate,…
How about "git, but actually usable".
I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mea…
Too many programming languages leads to too much fragmentation, not enough programmers well-versed in the languages, etc. Most times, we pick a language today based not on how optimized the language is for the problem, but on the availability of programmers who know how to use it. Haskell might be great, but if you're a business trying to build something, you'll have a much easier time hiring experienced C++ programmers. However, different languages have different strengths and weaknesses and applicability to certain problems, so you don't want to just standardize on one either. You probably wouldn't use Haskell on a project that is a good fit for C and needs low-level access to hardware.
It's not much different with version control, except that fundamentally all such systems aim to solve the exact same problem: managing and keeping track of source-code changes in a project. They go about it differently (distributed vs. non-distributed is a big factor), and offer different features, but they all want to do the exact same thing. And here again, programmer familiarity is an important factor. Working with git is not even remotely like working with ClearCase, for example. So people tend to gravitate towards popular choices, which was SVN before, and now has become git. So if you pick Hg for your project, you're going to probably have to spend more time getting contributors up to speed on it than if you picked something more popular like git.
One big factor in these debates is: how easy is it to change from one to another? Another is: how easy is it for individuals to pick their favorite and use that regardless of what others use? For programming languages and version control, you can't easily change between them, and everyone needs to be using the same one on a particular project (unless you do something where one part is written in one language and linked to another part in a different language through bindings, but this doesn't apply to version control). For editors, this isn't the case usually: any programmer can use whatever they want for the most part, and it has no effect on what others use.
As for your other examples, build tools are the same as version control: everyone has to use the same one on a project. You can't have one person build with make/autotools and another with scons and another with CMake. This doesn't mean you can't change it later if there's a compelling reason, but there's inertia to overcome once a project is built a certain way. ASCII did win, that should be obvious. Even Unicode is largely based on ASCII with utf-8.
Earlier quoted context omitted.
> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…
> Ouch, yet another way in which running on Windows can lead to poor technical decisions. I've never heard from anyone that choosing/using Mercurial was a poor decision. Are you biased?
Edit: to be clear, the kind of "everything" I have in mind is the code review system which now has to support two version control tools. Indeed if we'd used git from the start there might well have been an off-the-shelf code review tool we could have used without putting multiple man years of effort into customisations.
I was a Mercurial crew member for a few years (2008 to I don't know) and was very happy to be able to learn from Matt in his role as BDFL. His principled stance against layering violations and his policy to require really small commits still influence my coding every day. I hope he finds something new to give him satisfaction/joy!