> On Wed, Feb 22, 2006 at 11:04:24PM -0600, Philip Hallstrom wrote:
>>>> Using Subversion, as you say, you commit once your code is done and
>>>> tested. But in this scenario it cannot be tested until the code is on a
>>>> server; it cannot be tested locally (see below).
>>> No, you commit to the development branch once you are satisfied that your
>>> changes look ok and it is time to test. Then you test by pulling up the
>>> testing vhost on the server in your browser.
>> The problem is that designers can't even see if things "look ok" without
>> putting the files on the vhost first. No way they will make a blind
>> change, commit it, test it, repeat. They just won't :)
> Bust isn't change-commit-test-repeat the same as their current
> change-ftp-test-repeat process?
Almost, but not quite. There are many times the designers need to nudge
an element around pixel by pixel until it fits just right. Is it 5
pixels? 10? 20? Usually you just move it around a bit until it goes
where you want. I don't think those individual moves should be separate
commits since they aren't relevant.
Kind of like if you re-arranged your living room. How you got to the
final result isn't relevant. As long as you remember the original setup
you can go back.
Mostly it comes down to knowing the designers and I just don't think
they'd do it. And if they won't do it, then svn won't get used. And my
life will be miserable :-)
> At my previous job where we rolled out
> version control to both developers and designers, they grumbled about
> being forced to use it and how "slow to their process" the
> change-commit-test-repeat was .... until they screwed something up and
> version control was able to roll back the changes in seconds instead of
> hours of recovering by hand. They stopped grumbling :-)
Yeah. I'll be yelling the "update every morning", "commit all the time"
mantra a lot I'm sure :)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 23 17:51:16 2006