linuxppc_2_4_devel from denx vs. bitkeeper

linuxppc_2_4_devel from denx vs. bitkeeper

[brian.auld]

I understand that ppc.bkbits.net is the root repository for the
linuxppc_2_4_devel tree. I am also using DENX ELDK for a 440GP embedded
project ... the linux host development box being and x86 based RH8.0
machine.

Question: What is the difference between using the kernel source found at
the denx website, versus cloning/rsynching directly from the root
respository. I know the denx Makefile is different from the root repo
Makefile ... in a good way as it allows my ppc_4xx kernel to compile.

Going forward, I want to have (a) a kernel that compiles and (b) a
relatively easy way to rsynch any desired updates into my kernel in a
relatively painless manner.

My current throught is to use bkbits and modify the Makefile according to
DENX in my local custom kernel branch. I can then rsync according to bkbits
updates as opposed to using the DENX source ... which seems to use a
combination of CVS and BK.

Are there other differences (i.e. adding functionality) provided by DENX
that would make me want to use the DENX source instead? That's my basic
question.

Thanks again,

-- Brian

p.s. I've been trying to understand what potential differences there are
between the 2 kernel trees by diffing specific releases ... but with the
DENX source being CVS controlled and the root repo being bk controlled, I'm
having a tough time, even after sucking out the CVS and SCCS dirs.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: linuxppc_2_4_devel from denx vs. bitkeeper

[Wolfgang Denk]

Dear brian,

in message <995FF289C9D69747A09E42992644595405B2367D@penguin.adic.com> you wrote:
>
> Question: What is the difference between using the kernel source found at
> the denx website, versus cloning/rsynching directly from the root

The difference is that we are free to put any stuff we like onto  our
CVS  server, but to make something go into the "official" source tree
is often a time-consuming and frstrating experience.

[I don't want to start a lengthy  discussion  again.  I  pretty  well
understand the reasons why things are as they are.]

> Going forward, I want to have (a) a kernel that compiles and (b) a
> relatively easy way to rsynch any desired updates into my kernel in a
> relatively painless manner.

Use bk (and probably CVS) ;-)

> My current throught is to use bkbits and modify the Makefile according to
> DENX in my local custom kernel branch. I can then rsync according to bkbits
> updates as opposed to using the DENX source ... which seems to use a
> combination of CVS and BK.

We use CVS only for all of our work, but we are forced  to  pull  the
sources from the BK archives.

> Are there other differences (i.e. adding functionality) provided by DENX
> that would make me want to use the DENX source instead? That's my basic
> question.

You can expect to find bug fixes, extensions, board support and other
things in our version of the kernel source that will  never  make  it
into  the official tree for one reason or another. I don't like this,
but I cannot change it either. It's just  the  way  that  causes  the
smallest effort on our side. If we come up with an updated version of
a  driver it is a matter of minutes to check it into CVS. But it will
take hours and hours to break in up into all the atomic modifications
that I can submit as patches to the official kernel - and normally  I
also  should  test  all these little steps, too. Usually I don;t have
the time to do that, and not the patience either.

> p.s. I've been trying to understand what potential differences there are
> between the 2 kernel trees by diffing specific releases ... but with the
> DENX source being CVS controlled and the root repo being bk controlled, I'm
> having a tough time, even after sucking out the CVS and SCCS dirs.

Why? You can "bk export" one tree, and "cvs export"  the  other  one,
and then run "diff". Or you can generate the diff's only from our CVS
tree.  There  are  tagged  versions  which  clearly indicate which BK
changeset they correspond to. Also note the BK.KEY file in our  tree,
which summarizes this.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It's hard to make a program foolproof because fools are so ingenious.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: linuxppc_2_4_devel from denx vs. bitkeeper

[Wolfgang Denk]

Dear Brian,

in message <995FF289C9D69747A09E42992644595405B2367F@penguin.adic.com> you wrote:
>
> How do you manage CVS and bk together? In other words, how do you pull
> bitkeeper updates into your CVS controlled source tree?

Simply:  I  don't.  I  tried  several  ways,  but  probably  I  don't
understand  enough of BK to make it work reliably. So I just generate
patches between certain BK versions, which I  then  import  into  our
CVS.

> However, I ran a test to make sure this would work and ran into a problem.
> This is what I tested:

I tried similar things, and always  ran  into  some  cases  where  an
automatic approach would fail.

> Any words of wisdom??

Sorry, I'm neither a BK nor a CVS guru (but I manage  to  do  my  job
with CVS).


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.                                    - H. L. Mencken

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/