Large Capsicum patch for review.

[Warner Losh]

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.

> 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 to not complain when you use the word 'reliable'.

> 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.

> Using git-svn works really well and provides you with most benefits, which git has to offer, while using svn as the public repository.
> I have no experience with other systems like bzr or darcs, but from reading I gather, that they record sufficient metainformation, too.
> Even the marketing guys of p4 have a hard time to justify p4 compared to git.
> Read their git and p4 "comparison" (www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf), it's quite funny, if you know how to interpret it.

Can't speak to git in any of this. I've used it only lightly to snag other people's software. I do know what issues I've encountered with mercurial. Don't get me wrong, there's a number of nice features in hg, and it has been less problematic than svn or cvs, but much more of a pita than p4. Can't beat the price, for some environments it is perfect, but heavy branching it is still somewhat weaker than my perforce branching experience.

Warner