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/
