Auto commit on file modify with SVN (or git)?

Question

I've been reading and searching for a solution for a couple of days but haven't found anything that suits my needs.

We have frequently updated sites being updated by designers and developers that most of the time don't commit their changes to SVN.

I'm looking at continuous integration type solutions where, when a "versionned" file on the staging server gets updated, it is automatically committed to SVN.

CruiseControl and other tools I've looked at don't do this; is there a tool that does this or a better process we could use?

Thanks for any help!

Chris

Answer 1

I really like that you said "better process" because the answer there is yes.

Have your designers and everyone work from the repo. It doesn't matter if you choose SVN or git or something else, but make that the "authoritative" copy. Doing so will eventually save you headaches as you'll have a clear history of all changes, and can always revert.

The way I have setup a few environments for web design shops is with a system opposite to what you propose, it works like this:

• All designers work on checkedout copies of sites, and make changes and commit/update as needed.
• On commit, the repository pushes a copy of the site to a staging server, which is configured nearly identical to production.
• If the site is working on staging, there is very high confidence that it will work on the live server.
• When ready, the copy of the site on the staging server can be copied over to live, and now you have updated your site in a very responsible way and you have a history of all of your changes. (For this I like to use rsync, you can make it work however you see fit)

I hope this helps you think about your process somewhat.

Back to your original question: If you really don't want to change your process, you could set up a cron, that runs every few minutes and adds/commits all files that haves changed, and that should work. But I don't like this because now you don't have meaningful commit messages and the change history also might not make sense. As people are working and saving files, they aren't realizing at what point they are being committed, so more than likely there are now revisions in the repository that are a broken state, and now how do you find revisions that aren't broken? Choosing to "automate" the committing is obviously not the cleanest solution.