|
From: | Tupshin Harper |
Subject: | Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5 |
Date: | Sun, 24 Aug 2003 17:51:20 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030618 |
Tom Lord wrote:
This is all well and good, but when most tasks would need to be performed against all of the smaller units, then the subdivision isn't beneficial and just becomes an administrative hindrance. There are very few things that I would want to do with the kernel source that would be meaningful to do with only one part of the source.> From: Tupshin Harper <address@hidden>> Can you explain your thoughts on this? Do you mean (for example) that > high level kernel subdirectories would be different projects? Is there > any rationale for this besides arch performance? How would changesets > that span multiple projects work?Lot's of little rationales rather than just one big one. Here's some: Arch performance is one reason -- but the relevence to arch performance is relvent to plenty of other things as well. In general, when streaming the source in a "unit of management" through some process takes so long that it's uncomfortable, maybe it's time toreduce the "unit of management" size.
This is certainly the case, but for better or for worse, the linux kernel isn't strongly segmented this way, and I'm certainly not expecting to have much influence making it so. ;-) It's probably necessary to view the linux kernel as a severe corner case in respect to arch. It is one of the largest bodies of code that it will have to deal with, and it is simultaneously one of the least amenable to segmentation. That, combined with it's widespread use, is why it is such an ideal test case. If arch works there, it is hard to envision a body of code that it wouldn't work for.(and, again, the upcoming inode-signature optimization will greatly reduce the number of circumstances under which arch wants to read the whole tree and yadda yadda yadda. (But no such optimization is forseen for, say, grep, agrep notwithstanding.)) Another reason to partition the source when it gets that large is to make it harder to make the parts _that_ interdependent. It's a way to encourage better engineering.
Changesets spanning multiple trees? That's part of what configs are for. Committing a top-level, config-containing directory is effectively an atomic commit across multiple sub-projects.
Thanks..this is one area I haven't explored yet. -Tupshin
[Prev in Thread] | Current Thread | [Next in Thread] |