Date: Fri, 20 Apr 2012 20:06:14 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: obrien@freebsd.org, Doug Barton <dougb@FreeBSD.org>, freebsd-current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <4F920806.4040607@FreeBSD.org> In-Reply-To: <20120421003256.GB80419@dragon.NUXI.org> References: <4F91C8A1.7060400@FreeBSD.org> <1334956412.79181.YahooMailClassic@web113504.mail.gq1.yahoo.com> <20120421003256.GB80419@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/20/12 19:32, David O'Brien wrote: > On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote: >> Easier said than done. Feel free to give libedit a try. > That has nothing to do with our process and everything to do with us > blindly hacking away pissing all over to be our own thing -- BUT still > wanting to take work from the original author. > > I fail to see how not updating thru $FBSDrepo/vendor/NetBSD/libedit > is easier than updating thru it. > > Either way you have to figure out what to do with our great divergance. > At least when using the vendor branch you can use a good 3-way diff merge > tool (e.g. svn). > Usually the vendor upgrade approach works just fine if we do the periodic work of keeping up to date and we are careful to submit our changes upstream. The issue is that you really have to be in sync with one upstream version so that the changes you merge from the vendor branch are consistent. In libedit we have incomplete merges from upstream (that was CVS fault), we have some changes that are obsolete wrt to how upstream solved the same issues and we have a couple of files that have diverged completely from upstream. Either way it all can all be solved but it's just a lot of work and I can see how the direct approach helps understand better what is happening and can ultimately save time. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F920806.4040607>