I'm in total agreement...which is why I'm trying to overhaul our development process, which involves posting to Perlmonks to see what other people do since lots of people work where they can't run the webserver on their personal machines, and have more than one worker on the project.

So please don't stop the discussion...good answers are the only way to FIX my situation.

However, to soothe your fears somewhat, he is IN the source control, just not well. (Bascially he bugs a programmer to commit his changes). It's a kludge, and annoying, and it will break sooner or later, which is why I'm trying to fix it.

we have the same problem in our shop. and we (the developer) end up committing those changes for the designer. what i'm planning to have is a small cgi script that has a textbox for commit message and a button. that script should commit the latest changes of the whole tree. (or modify some svn web frontend to interact with the working copy... hmmmm).

teaching the designer to use that interface would be much easier than teaching her to use ssh

i've tried tortoise svn, but the problem is that the designer need to work with a running version and the webapp runs on linux.

Badai

(or modify some svn web frontend to interact with the working copy... hmmmm).

If you have Subversion set up with Apache2 and DAV then you can mount a repository as a file system on any modern Win/Mac box. This can be a very useful way of getting people to use source control without knowing that they're using source control.

It looks as if your *actual* problem is figuring how to motivate one employee to get in the version control loop. Allow me to suggest some possible motivation techniques:
• Money talks
  • If you are management, or can get management's backing offer to hire an intern who's job it is to simply check his code in for 1/2 the intern's salary. (ie. he's giving up half the intern's salary out of his own salary).
  • If you aren't management, offer to check his code in for him at $15 per instance, payable before checkin.
• If he's not going to check things in correctly anyway, make it a process. He FTP's the files to the test server, someone else tests his code, provides feedback and if successful, the tester checks in the code

-Scott

That's certainly _a_ problem. Our largest. But currently the instance scripts, templates, and modules are all version controlled as individual files, with nothing linking them as one "application". We have no automated testing at rollout. etc. I'm reviewing what's out there to decide what works best for us.