Gmail's tagline once was << Don't file, search >>. A commonsensical advice to deal with this ton of emails we keep just-in-case. But this can't be easily applied for commited projects. What is needed, then, is a simply stupid filing system.
There are lots of good filing systems. There are much more bad ones. (Almost every geek can speak from experience here.) This alone remains a very good reason to keep away from filing. What is needed, then, is a simply stupid filing system that prevents the geek-in-us to tweak it according to a sudden, brilliant intuition that seems to work but shows inefficient, arbitrary or plain wrong, one day, one week, or worse, one month after.
Among all the good, simple, and stupid one, here is three recipes that can't go wrong. Just follow some convention identifying everything you need to find back the files. A good example is Citeseer's [1] convention : (first) author's name, year of publication, and first word of the title.
Here is the first I follow : my initials (bstp) ; year and month of diffusion ; project name. That is a convention I find useful to put all the files that belong to the project, up to the date it was archived. So here is an example of what it may look like : << bstp200711cv >>, which is a current project about a curriculum vitae I am sending to a military college.
The convention applies to the directories, not to files. That is because it can be very difficult to coherently name all the files in all projects. The files in a project somehow tend to follow some internal, house rules, that justify incidently that it's been allowed one main directory for it.
Here is another one I follow, for year long projects : initials ; year ; name ; number for each document, according to the publication date. So here is an example, for this week's note : << bstp2007rwxa/20071119 >>.
This little trick prevents me from renaming, and renaming, and renaming again. Naming a file according to the title of the text it contains suppose that the working title is fixated once and for all. A very inefficient supposition. Every geek-in-us could speak here from experience.
The last convention I follow is to put old archives into yearly boxes. No need to zip these files : an archive is not a backup. Unless you can globally search into them, that would give some head and wrist aches.
Keeping orderly archives gives a sense of comfort. It gives some sense of pride too, since we archive what we did diffuse (publish, commit, whatever). These up-to-date archives can even give a very good idea of a curriculum vitae.
Looking for an old files is like asking yourself : << where did I put that again ? >>. Finding it, when files are ordered according to theuir publication date, is like answering : << when did I do it ? >>. The two questions are related. Taken together, they give a sense of what one did produce with the little space and time he's been allocated.
References
[1] http://citeseer.ist.psu.edu/
