In an earlier message, I wrote:

configuration option.

Someone asked me privately why anyone would want to open a bunch of files for edit that I wasn't intending to change, instead of leaving them Read-Only. I thought I'd reply for the entire list since it's a good question.

The main situation I have when this comes up is this: When I create an installer package (and this applies to both Windows. Mac OS 9, and Mac OS X - I don't do Unix, so can't say there...), there are usually a variety of files, like Read Me files, help files (LOTS of these...), scripts, etc. which are taken intact from the Perforce depot -- no building needed. The problem is, if you leave them Read-Only, then more often than not the installer will keep that attribute when installing the file on the customer's system. This can prove a problem later when the user reinstalls, upgrades, or uninstalls -- the Read-Only attribute can cause prompting for confirmation or even failure of the install/uninstall process.

I have a couple of alternatives to solve this:

1) I can manually change the file attribute to Read-Write before building the installer and restore it after. On Windows this can be done using the attrib command, on Mac OS X using chmod. On Mac OS 9, it's not very easy to do this at all, and in all cases you may have a whole directory tree of files to deal with, making the process tedious at best. And the whole thing needs to be reversed again or Perforce will get confused about the state of the files on the client.

2) I can avoid having to restore the attributes in #1 by copying the files to a seperate area and changing their attributes there, but it's just as much work.

3) I can use Perforce to open an entire folder in the Depot (and recursively all of it's files), then revert the unchanged ones later. By far the easiest and quickest way to do the job, and in keeping with the Perforce Way -- Perforce always knows the state of the client in this case.

So that's why you might frequently open a bunch of files for edit and revert most or all of them. In the specific example I was mentioning in the earlier message, I open my entire installer folder hierarchy for edit, build the installer using an installer description file near the top of that hierarchy (which changes that file as a side effect), revert everything else and submit that one file. I probably do that 2-3 times a week during alpha/beta cycles.