On 5-Jan-06, at 10:57 AM, John Peacock wrote:
> kfogel@collab.net wrote:
>> Frankly, I don't think we even need a config control for this -- it
>> ought to be the default behavior.
>
> What heuristic are you proposing to use as to when the file
> extension is "significant" (i.e. denotes some specific file format)
> and when it isn't? Or are you thinking that the conflict filename
> will simply strip off the last filename component, insert the
> conflict extension(s), then re-add the previous terminal component?
I don't feel good about this idea for exactly this reason. File
"extensions" are an unfortunate de-facto standard... there are a few
reasons that they are really bad way to identify a file "type".
Other filesystem meta-data is better for that. (E.g. like in the old
days on the Mac filesystems, even Mac is moving to "extensions" now -
presumably because no other OS's or filesystems clued in.)
The primary advantage to the file extension mechanism is the obvious
visibility of the extension (though Windows sets the GUI shell to
hide the extension by default and confuse users even more - a
Microsoft "innovation" no doubt). The extension conveys the
information easily without needing a fancy multi-field UI.. it just
does so with no real way of telling if the file is the "type" the
extension would lead you to believe it is.
Most programs will let you open any file, just by changing the
options in the file browser to show "all files" instead of those
ending with a particular pattern.
I suppose if this is a client-side optional thing that isn't forced
on everyone then I have no objections. But as others have pointed
out, it can easily backfire.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 5 18:54:05 2006