Large Capsicum patch for review.

[Warner Losh]

On Mar 1, 2013, at 12:33 AM, Christoph Mallon wrote:

> On 28.02.2013 00:08, Warner Losh wrote:
>> On Feb 27, 2013, at 3:41 PM, Christoph Mallon wrote:
>>> On 25.02.2013 15:21, Warner Losh wrote:
>>>> On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote:
>>>>> On 24.02.2013 20:30, Pawel Jakub Dawidek wrote:
>>>>>> Nope, but I'm using some script to generate patch(1)-compatbile diff
>>>>>> from a perforce diff.
>>>>> 
>>>>> Ugh, why is p4 still in use, if it is just a hassle and hides history?
>>>> 
>>>> Because it is the only VCS that doesn't suck at merging? While git, hg and svn do a passing fair job, they all suck compared to perforce.
>>> 
>>> Uh, no.
>>> git's and mercurial's merging logics are reliable and fast.
>> 
>> You must be using a different definition of 'reilable' than I'm accustomed to. It certainly is fast, but isn't as reliable and robust and perforce. Having used both heavily in branched environments, I can state unequivocally that perforce of 2003 did a better job than mercurial does in 2013. I've had more problems with mercurial than I ever had with perforce.
> 
> I really like to see an example.

It is hard to provide an example when proprietary source is involved.

However, some concrete examples of hg failing me:
(1) Pulling a new tree with patches from a patch queue applied is not 100% reliable. Sometimes it gets into a weird state that I have to unwind with bruit force.
(2) Create a branch. Commit changes to that branch. merge the mainline. cherry pick changes into the mainline. merge. After several iterations of this, the merges collide on previously merged items sometimes, but not always. The merges to the mainline also have increasing issues, some that it legitimately should have, others that it shouldn't. When doing similar work with perforce I never had these problems.

> From time to time I hear the statement "my VCS X does better than VCS Y, I have seen that many times.", but in the end I never got an example.

It is hard to give an example of fail when the problems are so complex.

> Of course, there are examples for CVS and old SVN, which do not record merges at all, but I want to see a case for systems, which record merges.
> I have seen cases for newer SVN, but these were blatant bugs in the implementation and I really hope, they are fixed by now.
> If you merged and a new file was merged in, but you already had an untracked file with the same name in your working tree, then SVN silently dropped the new file, i.e. the file was not merged at all and therefore missing after the merge.
> This especially happend, when you first did a trial merge, then reset, which left the new files untracked in place, and did the merge again.
> I do not have too much experience with mercurial.
> I mostly use git, in particular git-svn for FreeBSD, and it works really well.

Yea, I have little experience with git, just taking issue with your characterization the mercurial's branching is robust.

>>> The fact, that a merge was performed, is encoded into the structure of the history, which makes the history a directed acyclic graph, not just a simple tree.
>>> This information is considered when performing merges.
>>> Further, there is some logic to handle cherry picks.
>>> Another important aspect is, that you prepare merge commits (and in fact every commit) locally, so if something went wrong, which shows up during testing, you can correct it locally and then just publish the finished, correct commit.
>>> So commiting in general is not an open-heart surgery thing, which is great benefit.
>> 
>> Sure, it is a lot better than CVS, but it is no perforce. while mercurial does let me prepare the commit(s) locally, which is a plus over perforce,
>> it has mismerged things too often for me
> 
> Please, show one of these cases.

Again with proprietary software, that's hard to do. You wind up with a file that has the chunks in really weird places sometimes, usually times when the diffs are a bit weird (meaning that hg diff computed the diff in a way that wasn't as minimal as you'd like).

>> to not complain when you use the word 'reliable'.
> 
> I do not understand this part of the sentence.
> Is there are negation too much/missing?

Simple language: hg branching is not reliable. It usually works, and when it does it is great. It doesn't work 100% of the time, and when it fails the fails can require a lot of digging out.

>>> Since svn grew recording mergeinfo (in 1.5, if I remember correctly), it works ok, too, but it is really, really slow and has some other problems.
>>> Before 1.5 it was pretty much the same as cvs, i.e. it recorded only the branch point.
>>> For repeated merges, this meant, it tried to merge again the same stuff starting at the branching point, which lead to conflicts with later changes at the same places.
>>> So you had to manually specify, what should be merged.
>> 
>> Newer subversions are only marginally worse than mercurial from what I've done, but my recent experience has been much more slanted to mercurial than subversion, so that impression suffers from a small sample size.
> 
> Subversion is plain too slow.
> The most extreme case, which I experienced, was git having finished a moment after I hit enter, while svn took half an hour, because even though the merge was simple, many files were involved and all the trips over the internet took their toll (Also the bug above hit. This was the point, where we switched from svn to git).
> Also creating and checking out/switching branches is cumbersome.
> It got better with the ^-notation for paths, but it still is not on par with "git branch foo" and "git checkout foo".
> The fact that creating a branch also creates a commit is cumbersome and inspecting merged history is poor (compare with git log --graph [optionally also add --oneline and --decorate] or hg log -G).
> Interestingly, there is one thing, only git gets right:
> git log (and many other commands) spawns a pager.
> Plain hg/svn log is useless, because all the history scrolls by at full speed.
> You end up typing hg/svn log | less all the time.

Yea, subversion is a big pain for anything but 'dolphin' branches. And again, my complaints with what you say are 100% focused on characterizing hg as reliable.

Warner