Skip site navigation (1)Skip section navigation (2)
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>