On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:
Tom Rini writes:
quoted
On Thu, May 10, 2001 at 06:38:02PM +1000, Murray Jensen wrote:
quoted
quoted
Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
has been replaced with a linuxppc_2_4_devel tree. Could someone in the
know please post a quick update what this means, and perhaps what the
future holds wrt 2.4/2.5 linuxppc (embedded)?
I was hoping Cort would mention this here, but 2_5 has been 'dead' for a
while and is finally gone too. There's still mirrors of it however.
It will exist again, but when 2.5.0 appears and will be based off the
linux_2_4 tree or so. Right now 2_4_devel isn't up to date wrt 8xx/4xx, and
some new boards 2_5 had. I'm working on it. :)
Oh, lovely.
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 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. 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. :)
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. 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, 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
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tom Rini writes:
On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:
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.
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.
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.
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?
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.
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/