Chuck Peddle Peer of Steve Jobs and Bill Gates Who Transformed PCS Dies
wsj.com1 ポイント投稿者 eire11300 コメント
* Light weight branches for short development
* Ability to squash / fold - mutability
* Ability to rebase - mutability
With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops. * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”.
* Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero.
* Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial.
Benefits: * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble
* TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics.
* All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones.
* Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset. >>> class A:
... def __a(self,b):
... return b
...
>>> A()
<__main__.A object at 0x0000024EE5B0EBE0>
>>> A().__a('b')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'A' object has no attribute '__a'
>>> a=A()
>>> dir(a)
['_A__a', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
'__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']
>>> a._A__a("b")
'b'
In practice, I have never seen this used and just confuses things - and for dev's coming from Java / C++ or some other language it tends to just confuse things.