From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:08:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5CC33476 for ; Wed, 27 Feb 2013 23:08:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 218D6964 for ; Wed, 27 Feb 2013 23:08:25 +0000 (UTC) Received: by mail-gg0-f179.google.com with SMTP id h4so177702ggn.10 for ; Wed, 27 Feb 2013 15:08:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=euUjMpWCxz2vmuKHJn0EOL6BjyomMjXpl7zXX0WAOKY=; b=p02U4Q9ujIEGgtwmHPHQha9RkTvO28/80zU+Yc+ZXJFBa75gGPbl4UWVyWxPZWaztK wmO09u0mTQ2na0R+XkrGNLobhO94wafJ9zDl6rJr+WT3GobDs8ao/WK7EaW5xrdlS/Y5 paB8jphwFTwjbRJutXzuUZ0fxLfHuaDDCyHdcfxCIcHTfgYcK39YErB0pTe1TEfiw2si GuboXxRnIK9jWm7krhnUzmE3T2NQ3vUPbC+40bbPqwrxc8tR0zZ/VWr9lTUYhatBjBAo fsPwx8Xq8/y4d3RD7DXQcUE8XFOSrSKbBwHLYq9Ol4fWiO5a1KeaRp21t9PtbSujUX/f U9yg== X-Received: by 10.236.125.77 with SMTP id y53mr3213126yhh.14.1362006504392; Wed, 27 Feb 2013 15:08:24 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id k2sm6131218yhn.26.2013.02.27.15.08.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:08:23 -0800 (PST) Sender: Warner Losh Subject: Re: Large Capsicum patch for review. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <512E8B82.5040801@gmx.de> Date: Wed, 27 Feb 2013 16:08:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> <512E8B82.5040801@gmx.de> To: Christoph Mallon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkxDCKwzG81Xci17IdgR0vPnj/Cq+gYjE2cMQfvu/1DnzY+SvlcCj7BwIZu2B6hr1Q4IoMO Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:08:25 -0000 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. >>>=20 >>> Ugh, why is p4 still in use, if it is just a hassle and hides = history? >>=20 >> 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. >=20 > 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=