Date: Fri, 01 Mar 2013 08:33:52 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: Large Capsicum patch for review. Message-ID: <513059E0.8070503@gmx.de> In-Reply-To: <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> <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >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. 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. >> 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. > 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? >> 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. Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?513059E0.8070503>