Wed Jun 2 15:23:44 CDT 2010
On Jun 2, 2010, at 2:06 PM, Nathaniel Smith wrote:
> On Tue, Jun 1, 2010 at 4:33 PM, Travis Oliphant <email@example.com> wrote:
>> I really think this is more about how people view commits to the trunk than anything else. I like to use SVN as a version control system. My commits to trunk are always more incremental. I like to get things committed in self-contained chunks. Adding the requirement to put in documentation and tests before committing stretches out that "incremental" work element to longer than I ever have time for in one sitting.
>> Clearly, if I were using DVCS to a published branch that could be then merged to the trunk this problem would not have arisen. I see that I need to move to that style. People are reading far more into my committing to trunk than I ever meant to imply.
> I remember when I first started hacking free software, this was the
> model that *every* project used, and when people started talking about
> "always releasable trunks" it seemed like the weirdest, most unlikely
> concept ever. (I guess that makes this a generational thing?) Having
> finally wrapped my head around it on a few other projects, though, I
> can't imagine ever going back. Those "rules" and "procedures" are
> about as jackbooted as a dayplanner or a todo list... they let us
> avoid all the stress of having to remember which pieces *have* to get
> added before a release can happen, accidentally crashing into other
> people's work, having big debates, etc.; we can just get on with
> hacking and the resulting code is even better. (Because *everyone*'s
> code is better for being reviewed and tested. Even mine!)
> The other thing that helped reconcile me to this style of development
> was figuring out how to make testing less of a chore. Personally, I
> can't deal with TDD -- I don't understand how people know what the API
> should look like (to write the test) until they've written the
> implementation! But a much simpler method works for me: I never would
> commit code without at least *running* it, so now I've trained myself
> to just type those "hey, does this thing I just wrote work at *all*?"
> lines into a test function instead of a REPL. And while I'm sure there
> are all sorts of wonderful virtues and maintenance benefits to having
> a test suite, the real reason I do this is discovering that while I'm
> actually hacking, it's way easier to hit the 're-run tests' button
> than it is to re-copy/paste that line of code into the REPL. Kind of
> embarrassing in retrospect...
> No idea how any of this applies to others, but maybe someone will find
> it useful.
I found it very useful. Thanks for sharing your experience.
> -- Nathaniel
> SciPy-Dev mailing list
More information about the SciPy-Dev