zen
Important notice for people coming to Mercurial from Subversion: Hg is not SVN. Free your mind.
created and curated by alexandru totolici
Important notice for people coming to Mercurial from Subversion: Hg is not SVN. Free your mind.
Git makes this process incredibly easy and it changes the way most developers work when they learn it. (looking at cheap, local branching)
Speaking of tools and workflows: this is why many developers express both love and hate for git-style branches; gits1 tend to enjoy them and argue that nobody else has them, which makes git great; everyone else says the feature is irrelevant for comparison because of the complexity of dealing with it.
The comment above seems to imply that git-style branches are desirable, but that doesn’t follow immediately: the added complexity comes from a particular workflow design, one that satisfied Torvalds and the Linux kernel team, but one that may seem unnatural to a lot of developers choosing between the two. Blank statements like this are dangerous as they imply that a certain workflow is superior, when clearly it is not: even git users prefer local clones instead of branching, because a folder on the fiesystem may be easier to grok for some.
It definitely isn’t a convincing argument for why git is better than anything, and it’s a clear attempt to ignore the fact that different tools work for different people (because of different workflows).
or gitters, though I like my way better… ↩
Source: whygitisbetterthanx.com
I’ve been involved with Mercurial for only a brief period of time but I’m loving every moment of it. When I chose Mercurial over git, I did so despite the latter’s royal (Linux) bloodlines. I haven’t regretted my choice at all, and I’m more and more convinced that it was the good one as I’ve become involved with the project more.
But git and Mercurial have something in common: their shared dislike of Subversion. It’s much less prevalent in the Mercurial camp, but Torvalds’ introductory git talk at Google did pretty much massacre Subversion. Joel Spolsky called Subversion a path to brain damage.
I’ve unleashed caseguard upon the world, in an announcement to the Mercurial-devel mailing list sometime yesterday. I’m thankful for all the feedback, and I’ll keep improving this to make it as useful as possible.
What caseguard mainly does is protect users from adding certain files to the repository. Namely, while on Linux filesystems foo and FOO are different files, on Mac OS X’s HFS+ (in default mode) and on Windows filesystems the two are the same, so they’ll fold into one. This results in a case-folding collision, which messes up the repository. Caseguard simply protects users from adding files that would cause such problems in the first place (even though their own filesystem may allow it).
There’s additional protection for hg rm (don’t remove files if the case doesn’t match what the repository is tracking) and basic addremove support. The BUGS file will always have up-to-date information on known issues and limitations.
If you’d like to suggest further improvements or if you have any bugs you’d like to report, please use the BitBucket repository for caseguard (incidentally, that’s also where you can get the code from).