Problem: The hosting company (Mosso) that our clients are on does not offer shell access, only FTP. We would like to use subversion to keep all files under source control with each website having a separate repository. (Changing to Mercurial or Bazaar is not an option.)

Failed solution: Initially I worked on a post-commit hook script that would upload the most recently updated files. My co-worker mentioned that often times the changes made in one revision shouldn't be made "live" and this script would lack the control to upload multiple revisions.

Possibilities: Since I need to generate a list of files that have been changed, I can get that information from two places: svn log or svn diff. svn log is helpful because it can be exported as XML and will tell me when files have been moved. svn diff is useful because there is a --summarize option that will "flatten" the output - files modified across multiple revisions will be listed only once with the final change.

Snags: As alluded to earlier, I need to be able to identify files that have been moved, as svn diff may just show the file as deleted and added again elsewhere. This isn't a huge problem until the files are huge (such as flash movies). But I also need to "flatten" the changes, that is, if a file has been modified in two revisions, it only needs to be updated once. svn log only shows the modifications per revision and will not "flatten" the log.

Further considerations: Using FTP to recursively add, delete, and rename directories could be problematic. Also, I don't want to clobber files in the event that they have been updated outside the source control - perhaps checking the last revision date and/or file size (which is problematic if the file was uploaded in ASCII mode and not binary).

Questions: Is there some obvious / easier approach I should be taking? Does anyone have any recommendations on how to go about this?

I'm really appreciative of anyone who took time to read this, and will accept anything from full blown scripts to code snippets to suggestions of "best practices" to harsh rebukes.

Thanks,
Bob