I would also go down the revision control system route, however I would recommend a centralized server system , like subversion or cvs or perforce...
This would have the pro's that Perderabo was talking about, but the file could be available across the enterprise, cutting out the issues with FTP and other file transfer methods. It would give you a versioned file that you could tell who editted last, it can be rolled back, and most importantly the file can be accessed on any system, including using GUI clients. For example we have people in documentation that need to update html documentation on our product. They dont know, and dont wish to know unix. So they use a GUI client called "tortoise svn". This plugs into the Windows Explorer, and they just change the files naturally on windows using their favourite editors, etc. Once they have finished their editing they commit the changes and they're done. On the unix side, then when we build the product we drag these files in (the line endings are automatically mapped from CRLF to native line endings), and build the product. If we need to make changes, we can change the html files with the editor of our choice on UNIX and commit them when required. If we find an error introduced, we can look at the revisions, see when, where and who introduced them, and correct it, or roll back the version of the file. The files can then be centrally protected using passwords and access control, and it can be centrally backed up. We do this for every file we produce - code, images and documentation. I hope this helps...