From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 17:36:19 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 6D673BF3 for ; Fri, 1 Mar 2013 17:36:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 31E2BB46 for ; Fri, 1 Mar 2013 17:36:19 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id q15so496015yhf.19 for ; Fri, 01 Mar 2013 09:36:18 -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=eaypYdnxCXEbJPjyz2g8fN+F0AXKdQ6C1JJIN7dH9nY=; b=A8gXiXpc7Yf/Ki1hUljaNNfnOPmCHH3SgFh0mv17PpORok+vepVtNDNeUkqAFAl4XO mHnEQtCWuzxo3pCHeVHc396U0ckj2YWEhW7pcn9z+lAJJ94616JBJN5k8mUBMg1OtFE6 zH1xF3nHjhyQpzbr3hYN+YG7aQx57AIlu/kTc/bVRlG8E+fWK/g/p1w/mysgtX/l/ZiG fxbTDR35vKQlANQ1oFdKjdYkzZmA0+G2bwln11dkRdp/uaJJzRzi0a1pT91YtG5ne9Mn in+jRc5LocV+OkW5Ued9bFtIEOX5pD5R3iuwEUF6D8GlEmVTZwgAzJCnQlR4rfff2G0S /1MQ== X-Received: by 10.236.193.102 with SMTP id j66mr7736490yhn.195.1362159378778; Fri, 01 Mar 2013 09:36:18 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id w7sm20057969yhj.0.2013.03.01.09.36.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 09:36:17 -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: <513059E0.8070503@gmx.de> Date: Fri, 1 Mar 2013 10:36:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> <513059E0.8070503@gmx.de> To: Christoph Mallon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnQK/RVmuPe+90F1OmkUonSi/dosGrKfbk9QHKjzW9hDEDS1LkOoWzQOdA9uMLxwez1yUvz 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: Fri, 01 Mar 2013 17:36:19 -0000 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. >>>>>=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. >>=20 >> 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. >=20 > 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. > =46rom 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. >>=20 >> 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 >=20 > 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'. >=20 > 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. >>=20 >> 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. >=20 > 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