Re: linuxppc_2_5 source tree (and others)

On Thu, May 10, 2001 at 03:46:54PM -0400, Albert D. Cahalan wrote:

Tom Rini writes:

quoted

On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:

quoted

quoted

I'm very glad to have ignored this BitKeeper nonsense for
the most part then. I knew there was a good reason to rely
on the one true source tree from Linus. I'm not screwed like
all the people working from linuxppc_2_5 are.

Right.  But the "one true source tree from Linus" doesn't always
work for other arches.  Why?  Keeping stuff in 100% never works.
There almost always has been a slightly more up-to-date tree than
Linus' for ages (when did the first -ac patch come out, anyone

The 2.2.14 kernel is over 15 months old. I'm expected to run
Montevista's obsolete and severely hacked up 2.2.14 kernel if
I want to use a PowerCore 6750. So "slightly more up-to-date"
could mean over 15 months I guess.

No, but '2_5' is rather up to date, and should work fine.  MontaVista's
tree is what gets released with the official release.  There have been other
intermediate trees which haven't had the same quality testing the release
tree has.  But this really isn't about MVs trees, is it?  If so, this is a
rather odd way of going about it.  That said, I for for MV...

quoted

know?).  And, who exactly is screwed that's working from the old 2_5
tree?  There hasn't been any new activity in it for ages.

I nearly fell into the trap. Just recently, 2_5 was listed as
being where the latest development happens. It certainly looked
that way too, with support for more boards than 2_4 had.
Until just this morning, I was thinking I ought to use 2_5!

Well, you quite probably should for the moment since it should require little
work to get things working again in 2_4_devel.  In fact, if the board you're
working on doesn't have a 10x bridge on it, all the common files should be
there that you need.

quoted

  Shortly
(mainly once I'm done w/ finals) it'll be little more than exporting
your local changes from '2_5' and applying them in 2_4_devel.  Yes,
history bits will be lost, but such is life. :)

That defeats the purpose of revision control. You might as
well use "diff" and "patch" if you will be throwing away your
version history.

Well, this wasn't my decision to make.

quoted

quoted

On the other hand, I had to do my own PowerCore 6750 VME port for
the 2.4 kernel. That sucked. It would be nice if everyone had the
decency to submit stuff to Linus in a way that he finds acceptable,
rather than hoarding source code in obscure places that are only
accessible via non-standard non-free software.

So use rsync and import into your own CVS tree.  I think it sucks
too that bk isn't gpl'ed, but hey.  I don't really care that much.

The 2_2 and 2_4 trees were available via rsync, while 2_5 was not.

Oh, right.  I thought somneone else was going to put it up, but
oh well.

quoted

I'd wager your port would have sucked much less if you were working
off the 2_5 tree too (mvme5100 support is currently 4 mvme-specific
files, and some new common ones other boards use too.  Some pcore
boards are about as simple too).

So now you are saying I should have used the 2_5 tree?????
Wasn't I supposed to know (by psychic methods) that the 2_5
tree is 'dead' now?

Not at all.  In fact, unless you did the port w/in the last month or so
2_5 was rather much alive.  And I could have sworn people have mentioned
the 2_5 tree on this list numerous times...  Also, hust because
the tree is dead doesn't mean that the inforemation in it
is dead too.  It'd just be a matter of exporting your changes and then
re-importing them.

quoted

quoted

So, how did _you_ know that 2_5 has been 'dead' for a while?

Well, it was on the linuxppc-commit list, which Cort has mentioned a
few time (hence it's majordomo now and not a sendmail alias like it
used to be).  It's even mentioned on the page that talks about the
bk trees: http://www.fsmlabs.com/linuxppcbk.html

I figured that would be a list for automated check-in reports
generated by the BitKeeper software.

It is.  It also functions as an as-hoc list to distribute BK info over.

So anyway, we now have a 2_4_devel tree to wonder about.
Might somebody suddenly decide to delete this tree too?
Will changes get back to Linus, or is this a dead-end too?

Hopefully not, hopefully so.  Out of my area anyways.

Having separate trees also defeats the purpose of revision control.
One is supposed to use branches (or whatever BitKeeper calls them)
for stable, release, development, etc.

BK does this by letting you use seperate trees.  You can import from the
parent into the child (ie pull main into dev).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

bk trees: http://www.fsmlabs.com/linuxppcbk.html

Are these trees designed to work "out of the box" on boards such as the
Walnut?

When configuring I don't see any options for the specific 405GP ethernet
for instance.

Also, do I need a password or something to get the devel tree?  Am I
allowed to get to the devel tree?

As per the instructions on the page (adding -azv):

$ rsync -azv bitkeeper.fsmlabs.com::linuxppc_2_4_devel
linuxppc_2_4_devel
@ERROR: Unknown module 'linuxppc_2_4_devel'
$ rsync bitkeeper.fsmlabs.com::
linuxppc_2_2
linuxppc_2_4
$

Thanks,
Ira Weiny

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