conflating revisions… I think that this is unneeded, and in fact probably harmful.
Its not needed because (generally) if the amount of history is large enough to be of concern with todays systems, its either a very old project (i.e. coreutils with 20K revisions on its mainline (which is trivially handlable today)), or a very active project where the bulk of history is, well, recent. The cases where you have lots of old history and a slow rate of growth are the exact cases where our technology will outpace the projects accumlation of history.
Its harmful because it violates one of the basic things users expect from a VCS tool – the ability to get their code as it was.
Theres an interesting rant on why JUnit wasn’t suitable for this guy ‘Mike’s tests, with the primary reason as I understand it that he creates X number of dynamically created tests and runs out of memory.
Whilst agreeing with him – if you aren’t writing unit tests, xUnit may not be the right tool … I think he would have been better served with something along the lines of (in python):
class DynamicTests(unittest.TestCase):expectedCount=1000def countTests(self):return self.expectedCountdef runTest(self):for int in range(self.expectedCount):do_whatever_to_test_this_case
The point being that the xUnit framework imposes No Requirement that a test case _be_ an instance – it uses a composite pattern, and any element can be a test case, a container for tests, or both. If you need to write many related tests that (for example) need to store no local state, require the same temporary resources, then leverage the nature of the composite.
Had fun today configuring a sid chroot in hoary:
1) cdebootstrap doesn’t setup signed package verification correctly, so it fails.
2) in the failed chroot, configure up apt with a debian sid mirror, and install cdebootstrap
3) now cdebootstrap sid sid
4) move the sid bootstrapped sid chroot back out, and then remove the temporary borked one.
This will impact sarge users too – but is it really a bug ?