>--- Forwarded mail from [EMAIL PROTECTED]
>>(....)I do not advocate combining the two
>>methods on the same set of source files. However, I do advocate combining
>>the two methods in the same project, applying the locking model to the
>>specific source files that require it and applying the concurrent model
>>everywhere else. (Note that because the model is selected on a per-file
>>basis, the two methods can apply to the contents of a single directory,
>>which is a potential source of confusion.)
>Per-file is better than per-directory. Even thought you will not mix up the
>VB and C++ projects in the same directory, some C++ automated engines might
>want to lock few files as well (like '.odl').
Web sites that mix HTML sources and images in the same directory are
another example. HTML is mergeable, most images are not.
>>In my proposal, it would be a flag given at add time, plus an adminstrative
>>command to change methods later. An additional admin command would be
>>required to break dead locks. Locks would be communicated by diagnostic
>>messages displayed when multiple users try to lock the same version (only
>>the first wins), and perhaps by a broadcast performed by a *info hook.
>Yep, THAT IS IT! By default, of course, the file added without the flag
>would go to 'unlockable' category.
It's possible to try to recognize the type of file being added, as well.
The usual methods of matching wildcards or using some form of "magic" file
aren't perfect, but they can be tuned to an arbitrary level of correctness.
Whether or not such a method should be used is subject to debate; if it's
available, it should be highly configurable and there should be a way to
turn it off.
>--- End of forwarded message from [EMAIL PROTECTED]
