My understanding of TimeVault is that it takes "snapshots" of the filesystem; it might be too "heavy duty" for the intended use. Basically what I'm thinking about is to have a working copy checked out of SVN in a directory that would be monitored by inotify. That way while files are be worked on, several historical copies would be maintained in a separate directory (outside of the development area) so that when, say, I mess up the code I'm currently working on I could step backwards a save or two with little effort simply by picking up a slightly older copy from the backup folder. Commits to SVN would only happen when the code is actually working. With TimeVault my concern here is that obtaining copy of a file that was saved few minutes ago might be too much effort. The versioning for currently worked on items I'm looking for here is pretty casual, and it's mainly intended to prevent situations such as where one spends an hour hunting an inadvertendly introduced extra quote in a large JavaScript file. Many IDEs such as Zend Studio or even UEStudio of course provide "keep x previous copies" which might suffice.. except that I would like to keep the versioning tool-independent.
However, your suggestion for automatic commits to SVN based on an iWatch trigger might do the trick! It would certainly take care of versioning; the in-progress code could be always stored in a fork as not to pollute the trunk. In the past I had a reverse setup where I did a commit to SVN (or at that time to CVS) on every change/save, and a script then updated a working copy in the web directory. But that was a pain to work with as there was always a 4-6 second delay before the change would be reflected in the web folder and so in the browser refresh. If commits to SVN would be triggered by an iWatch event, it would occur independently from server side debugging (I'll use this this with zend server) and browser update. The only consideration would be configuration files and such which I would ultimately not want to commit to the trunk, but perhaps they could be pruned during the fork merge process.
I'll give this a try, and update this thread later. More ideas/thoughts are of course welcome! :)
|