From: Dan Pattison <dan.pattison@ethertek.ca>
To: buildroot@busybox.net
Subject: [Buildroot] Easy Upgrade Path?
Date: Tue, 10 Feb 2009 17:35:15 -0800 [thread overview]
Message-ID: <49922B53.50608@ethertek.ca> (raw)
In-Reply-To: <d6cda7730902091413h5e7cbd21ra41d7154ca60909e@mail.gmail.com>
Thanks for the reply Thiago. I will see if I can get a svn server going
and try your method.
Best Regards,
Dan Pattison
Thiago A. Corr?a wrote:
> Hi Dan
>
> On Mon, Feb 9, 2009 at 4:53 PM, Dan Pattison <dan.pattison@ethertek.ca> wrote:
>
>> I've been getting used to the buildroot development environment using
>> 2009.02-RC2 for ARM AT91SAM9g20-EK. I have made lots of changes and
>> additions that suit our project (config files, packages, etc.) We have
>> successfully compiled and included some of our own programs.
>>
>> What is the recommended method to upgrade to the newest build environment so
>> we don't have to re-do everything? Is this possible?
>>
>>
>
> I don't know if there is any recommended way. None is documented, and
> I guess each one does whatever they see best.
>
> I had the same problem as you, and after some thought I decided the
> best approach would be to "fork" from buildroot svn to my own private
> svn server (svn export) and do my changes there. I've also added a
> file upstream.rev which only contains the last revision from svn that
> I have merged from upstream (svn diff -r last:current >
> upstream-rev.patch && patch -p0 < upstream-rev.patch).
>
> The downside is that svn diff patches doesn't remove files removed
> from the repository, so you need to do that manually. This happens
> most often were patches are stored. A simple diff can catch those then
> you need to manually do svn rm in your repository.
> My own packages (code I've developed) I've added to
> package/mycompany/*, so, when I do a diff between buildroot checkout
> and my repository, I can easily mask that.
>
> Also, generic changes/development, I try to push upstream whenever
> possible. This both benefits other users and also helps us keeping the
> differences smaller, so merges with upstream are a bit easier.
>
> This is far from a good solution, but has worked so far.
>
> Hope this helps.
>
> Best Regards,
> Thiago A. Correa
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.19/1941 - Release Date: 02/06/09 11:31:00
>
>
next prev parent reply other threads:[~2009-02-11 1:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 18:53 [Buildroot] Easy Upgrade Path? Dan Pattison
2009-02-09 22:13 ` Thiago A. Corrêa
2009-02-10 9:00 ` Peter Korsgaard
2009-02-11 1:35 ` Dan Pattison [this message]
2009-02-17 20:56 ` Thiago A. Corrêa
2009-02-19 15:34 ` Peter Korsgaard
2009-02-12 13:29 ` Thomas Lundquist
2009-02-12 13:35 ` Peter Korsgaard
2009-02-12 18:05 ` Ulf Samuelsson
2009-02-14 16:52 ` Thomas Lundquist
2009-02-13 0:10 ` Hamish Moffatt
2009-02-13 2:05 ` Eric Malkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49922B53.50608@ethertek.ca \
--to=dan.pattison@ethertek.ca \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.