The other day I was happily programming in my cubicle. Overjoyed with excitement that I accomplished my task early, I wanted to quickly check my files into source control. Some files were no longer needed by the application. Using my handy source control tool’s UI, I selected the files (all the changed files) and clicked delete. Uh! Oh! I knew as soon as I hit delete (and the ok button on the “Are you really sure?” dialog) many hours of work were lost. I am no longer a happy programmer.
But wait… I am using IDEA, which I know can help me. IDEA has a great feature called Local History. As you code, run, debug, etc. IDEA is tracking and labeling your code. At any time you can ask IDEA to show you the local history of a file. The local history displays a colorful side-by-side comparison of the file. Simply find the code you want, copy-n-paste, and you are back in business. In the case of a deleted file, simply show the local history for the directory where the file lived. IDEA then allows you to restore the file. Really cool!
Brian Coyner’s Rules of Thumb:
- Always “sit on your hands” before executing a command to delete something.
- Use an IDE that supports local history in case you forget to sit on your hands.
Also use command line interface
I use the command line interface to interact with a Subversion repository. The same would apply to any other SCM tool with a CLI. For instance, I prefer the Perforce CLI to the GUI so as to avoid the kind of problem you encountered. The CLI encourages more attention to local modifications and to the subsequent commit than a GUI. In the case you illustrate, I would have deleted the files one by one as soon as I made the decision to delete them:
% svn rm
% svn rm
svn would not have allowed deletion of an uncommited file without a forcing flag.
Later I could always revert a file if I changed my mind:
% svn revert
Before commiting I would get a listing of the pending changes:
% svn status
D f1
D f2
A f3
M f4
By now I would be pretty sure of the commit.
% svn commit
A related matter is to commit frequently, usually at stages that do not introduce errors into the repository. This avoids losing work (even the IDE history is limited by default). Arguably, less reliance on GUIs is in the spirit of your XP book. When doing development including unit tests, I usually commit a few times per hour. When doing refactoring or redesigns I sometimes create a branch.