On Fri, Sep 19, 2008 at 10:12 AM, Jeff Nelson <stutterstutt at comcast.net> wrote: > Jon Schewe wrote: >> You've still missed the problem. The problem is if someone changes the >> server without putting the files in subversion. > > Not all problems can be solved with technology. I'll bet if someone > forgets to put the changes in subversion and loses them, he will have a > painful reminder not to do that again. He will either learn or he won't. > If he doesn't you have choices. > > However, that being said, there is a way to do what you want. > > On each server, run a script to compare the files on the server with the > files in subversion. If there is a difference, yell, scream, whatever. > Email the entire group with the notice that someone goofed, complete > with full details. (Peer pressure can be useful.) > > You can schedule this script to run whenever you want, depending on how > long you are willing to risk non-detection. > > An optimization comes to mind: find only those server files that have > been changed since the last script run and just compare those. > > I'll bet you could even figure out how to kick off this script as a > pre-commit action so each time someone tries to commit a change, your > script automatically runs. The commit is aborted if *any* file on *any* > server is different. Now the person who wants to commit will have to > stop and figure out what happened and why. (More peer pressure can be > brought to bear.) > Or, skip the post-commit step, and instead of running rsync, run scheduled jobs on each server to check the svn log, see the latest update, compare with the current date/time of the file on the server, and if the server's version of the file is newer than the svn version, do not update, but ring a bell. Cheers -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap.