On Feb 19, 2007, at 11:50 PM, Garrett Rooney wrote:
> On 2/19/07, Mads Toftum <mads@toftum.dk> wrote:
>> On Mon, Feb 19, 2007 at 11:31:12PM +0100, Leo Simons wrote:
>> > How does this look?
>> >
>> Like a bad idea? imho pulling in a library like redland really
>> should be
>> avoided if you can. Unless you're planning to have a pile of
>> patches to
>> redaland that won't go back to the mainline, I don't really see a
>> heed.
>
> +1, unless we're talking about a seriously large number of patches we
> should just make our build system link to an external redland. Third
> party libraries should only be imported as a LAST resort.
I've heard that many times, but I've never understood why. Maybe
someone can explain it to me?
(I know It was sort-of painful with CVS because of not having binary
diffs or diffs on directories or rollback, but SVN doesn't have those
problems.)
To me, vendor branches are just a very convenient way to track (or
partially track) downstream or upstream software very precisely (oh,
and you get "working copy semantics" for the "vendor" stuff too,
always nice when on a plane, and you're not dependent on the third
party its version control system being up, and you can diff and merge
across the vendor tree and your own easily, and and and <other stuff>).
Since I think its likely we'll stay ahead of actual redland releases
for a while (eg work with its trunk and have nice and fun cross-
pollination back and forth) and use it directly from SVN, my idea is
that "just doing it in SVN" is simply easiest.
I can swap fancy hot-download build systems with the best of them,
but I don't particularly enjoy using or maintaining them (someone has
always *just* updated the build to require a new version of a package
which you can't get because you're on the train, and you svn upped
just before getting on the train so yo can't roll back to the version
that works with the previous version so you can't really work test
first and things break down).
cheers!
- Leo
|