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.

(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.

• 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

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.

But currently the instance scripts, templates, and modules are all version controlled as individual files, with nothing linking them as one "application".

One thing that has helped me do this is to treat everything as a CPAN distribution. I use Module::Build which is pureperl (unlike ExtUtils::MakeMaker which builds Makefiles). It's also completely extensible, though the documentation could use a little work. So, if each of your items is their own distro, you can have the actual app's Build.PL indicate that it depends on Foo, Bar, and Baz, each having a minimum version. It also allows you to verify all your CPAN installs, the Perl version, and anything else you might need. Then, you put the Build.PL into SVN and you're good to go.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?