Date: Fri, 1 Mar 2013 10:36:15 -0700 From: Warner Losh <imp@bsdimp.com> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: freebsd-arch@FreeBSD.org Subject: Re: Large Capsicum patch for review. Message-ID: <A605ECE7-3A76-4021-9FB4-29A372BB8138@bsdimp.com> In-Reply-To: <513059E0.8070503@gmx.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A605ECE7-3A76-4021-9FB4-29A372BB8138>