This post (a bit longer than usual) makes a rash assumption that you've been using Worksets for a bit already and may have experienced occasional errors or crashes. You may just be curious about comments others have made about making new local files every now and then.
Read THIS if you wonder why there is a Local File at all? Here is a quick reference guide to Workset terms. If you are using Revit 2010 versions then you might want to read this newer post first.
I suggest you make a new Local File every day you work.
There are many operations in Revit that require sending a lot of data to your Local File. In fact every SWC (Synchronize with Central) usually pulls more data into your Local File than you are sending to the central file. You can avoid some of this data transfer by making a new Local File since a copy has the latest saved data in the Central File. When team members are participating in the project sporadically it is easy to have many hours of work occur between when you made your last Local File and starting work now. Making a new Local File ensures that you are working with the latest saved data.
Teams seldom work identical hours. Somebody leaves early, comes in early, works late etc. You may leave an hour or two before others. Let's say three people worked for two hours after you left. If my math skills don't fail me that's 3 x 2 = 6 hours of work you missed. If you come in the next morning before anyone else, open your Local File from yesterday it is at least 6 hours out of synch, possibly more if others SWC after you left but had not done so for some time before you left. If you don't immediately use Reload Latest (it is too easy to forget isn't it?) you will begin work without seeing at least six hours of work. For some six hours is a lot of work while others, not so much. If you made a new Local File this morning instead you'd already have those six hours of work and no waiting for Reload Latest.
You might even consider making a new Local File midday. Let's imagine Joe made more, possibly major, changes to the project titleblock and there are a couple hundred sheets in the project. He does this a little before lunch and does his SWC just after the team heads out for lunch. When you each return from lunch and open your Local Files followed with Reload Latest, you each have to wait while Revit pulls the titleblock changes to your file and updates each reference to it. This may not be a major amount of time but it is certainly more than if you made a new Local File and just opened that instead.
That's how often according to me...what about making them...how?
Prior to the release of Revit 2010 I recommended that Local Files should be created using Windows Explorer by copying the Central File from the server folder to a folder on the local PC. Don’t use File > Open followed by File > Save As because it is TOO EASY to forget to actually do the Save As part. Even though this is the recommended procedure from Autodesk this establishes a normal or habitual opening, by EVERYONE, of the central file, which should really be avoided. Don't establish bad habits! With the release of Revit 2010 they've provided a bit easier process for most firms to use.
Don't routinely open a Central File!
Not that you will necessarily harm the project file by opening it but teams should form a good strict habit of not opening the central file. There are acceptable reasons to counter this rule but they are not routine things that all team members will need to do. Their normal interaction with the Central File should always be limited to working through a Local File.
Copying a Central File is also FASTER! Though this copy/paste process is a bit obtuse it is actually faster than File > Open and then using File > Save As since you are technically opening the file twice with that approach. It takes much less time to copy/paste a file than one File > Open operation does, by far! See the second to last paragraph in this post to consider how to make it REALLY FASTER.
Where do Local Files go?
Assuming you follow the strategy of naming a central file like this: (note with Revit 2010 the following is also a less stringent recommendation)
Central File - On Server: ProjectName-Central.rvt
Note: Adding the -central makes the file different than a regular stand-alone project file. It is just a little more obvious that it is special.
I recommend using C:\Revit\Projects or similar, not the project folder on the server or any server for that matter. They should be located on the root of the C:\ drive (or secondary drive "D:\" on a PC if desired) because any team member can log into another team members PC, as themselves, to find that user's Local File should they fail to return all elements when they finish for the day. You want to avoid relying on IT to get what you need, or rather avoid bothering them, right?
Therefore "My Documents (now User Documents in Vista or W7)" or "Desktop" folders are not a suitable home for a Local File because only users with sufficient network permission can access them. It is also a good strategy to have a common location so keyboard shortcut files and any other customization a firm does can be stored there, in a consistent reliable location.
What about Naming?
I prefer to alter the Central File once it is copied to remove the "-central" from the name and substituting the user name and month and day (mm/dd) for the date created. This makes the file different from the Central File and special so others can distinguish between a stand-alone project and Workset project more easily. It also makes it different from the actual Central File. Revit doesn't care about that honestly but as a support person it does make it much easier, at a glance, to see if a team member is working in the Central File or not, that and the lack of a Save "Local" icon on the tool bar.
Central File - On Server: ProjectName-Central.rvt
Local File - On Local PC: ProjectName-Username####.rvt
Note: Do not use an extra period in your Local File name because Revit may interpret this to be a Backup File. Revit uses a period to designate backup files. Specifically do not name files with the combination of .####.rvt because this is the format Revit uses for backup files. A space is a good separator but a dash (-) or underscore (_) will work.
Local Files can go on the user's PC because they do not need to factor into the data recovery strategies of your IT staff. They can be regarded as temporary or working files that need no data redundancy or backup even though Revit does create a backup folder for Local Files. So don't worry about discarding Local Files. You can get rid of previous Local Files as often as you see fit. Keep them from the previous day or days if it makes you feel more comfortable. But discard them eventually.
As I wrote earlier I said there are acceptable reasons to open the central file. This is usually for maintenance of the project like using the Compact Central File feature to clean up the database and reduce file size. Opening the Central File directly should be reserved for the most knowledgeable team member or your office BIM/Revit/Data manager.
There are several activities that justify the use of Detach from Central as opposed to working in either a Local or the project Central file directly. This is a useful option that is available when opening a Workset project file, either a Local or a Central File.
As for the copy/paste process itself I always encourage firms that have someone who can write scripts or have programming skills to automate the process for users. Ideally the result is as simple for your users as a double click on an icon on the desktop to get started each morning. There is a useful thread at AUGI where members have discussed as well as posted some of the methods they've used. As I repeat endlessly here, you need to join AUGI to download attached files there. Again this isn't as big a priority now the Revit 2010 provides a pretty simple process that will suffice for many firms.
I've written quite a few posts about Workset features over the last few years, enough that I had forgotten about some and was surprised when I searched my own blog to provide some related links! If you search for Workset related words you'll find quite a number of things to read.