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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox