Wed Jun 2 14:06:29 CDT 2010
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
More information about the SciPy-Dev