linuxppc_2_5 source tree (and others)

[Albert D. Cahalan]

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

>> 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.

> 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!

>   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.

>> 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.

> 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?

>> 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.

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?

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.

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