On May 29, 2008, at 05:43, John Peacock wrote:
> Ryan Schmidt wrote:
>
>> It's contrary to the notion of committing things once they've been
>> tested, which I subscribe to. Whether this matters for the OP is
>> of course for him to decide. But in the web site development shop
>> where I worked, it's common for a programmer to make a small
>> change in the text file, save, press reload in the browser, go
>> back to the text editor, make another small change, save, reload
>> in the browser, back and forth very very quickly until they get
>> whatever it is they're working on right. To force them to commit
>> after every little save (and invent a commit description for every
>> new attempt) would slow them down immensely. Maybe this applies in
>> the OP's case too.
>
> Your mode of operation requires each developer machine to be
> configured with exactly the same server software as the main
> servers, which can be an extreme hardship (and sometimes impossible
> due to license requirements) depending on the software involved.
But that's exactly what our mode of operation didn't require, because
all working copies were stored in the developers' home directories on
the central Linux development server and accessed via Samba on the
developers' Windows machines. The server software (apache, php,
mysql, imagemagick, etc.) needed only to be configured on the central
Linux development server.
> It also speaks to a certain level of programming immaturity that a
> developer would have to repeatedly make small changes to get
> something working.
Did I mention I quit that job? :-) But I think we all have days when
it takes several tries to do something. Nobody's perfect. And I would
prefer that there be one commit to implement a feature or fix
entirely, not a bunch of half- (or even non-) solution commits.
> As a counter example, with your methodology if a developer gets
> something working, but then tries one or two more things and breaks
> it again, they have to remember what they subsequently changed to
> correct it back to working order. With my methodology, they just
> reverse out the last few changes and they are back with a working
> page. It is all too easy to say "I'll commit this in a second
> after I try /one/ more thing" and then not commit at all (remember,
> all programmers are lazy). ;-)
>
> Both methodologies have strengths and weaknesses; I prefer mine,
> even if it means that sometimes the log messages are "Dammnit does
> this work?" because it means that all changes are versioned (even
> the stupid ones).
I think you may be thinking of bigger changes than I am. I'm talking
about making several rapid changes to, say, the horizontal position
of an element of text until it looks right. Or tweaking a color until
it looks right. Or trying out various email encoding strategies until
it produces an email that looks right in the email client.
For a different scenario, take what I was doing before I read your
email. I'm trying to fix a problem building a universal binary of
some software on Mac OS X. I'm trying various things to make the
universal binary build properly. I don't want to commit every time I
make a change, because I don't yet know that my change fixes the
problem, nor even that it doesn't make the situation worse. To
determine this, I need to run the build. I only want to commit once
the build succeeds and the resulting binary works to my satisfaction.
In the same way, a web developer should not be forced to commit every
time they save their text document. They should only commit once
they've tested their changes and are happy that they solve the
problem they were setting out to solve.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-29 12:59:09 CEST