In a message dated: Thu, 25 Sep 2003 18:05:09 +0200
"Arild Fines" said:
>Isn't the dot in .svn itself an artifact of "accommodating OS-specific
>things"?
I suppose you could look at it that way. However, it is a legacy
design decision made (I'm guessing) before there was large non-UNIX
based users base. So, it was more fixing something which always
annoyed those coming over from CVS, and doing it in such a way that
would not break other environments.
>In particular, accommodating a platform broken in such a way that
>it needs obvious metadata like the hidden attribute embedded in the filename
>itself...? ;-)
Nahhh, it's taking advantage of an OS feature which does break other
environments. Relying upon OS-specific file meta-data like
'attributes'[1] would be, as you put it,
Arild> accommodating a platform broken in such a way that it needs
Arild> the hidden attribute
:)
In short, yes I agree that relying upon name-embedded meta-data is an
OS-specific mechanism. However, doing so doesn't break[2] the use of
svn on other platforms, and, having a common location has had some
benefit in the past.
Footnotes:
----------
[1] It would be nice to be able to use things like 'attributes' for
this type of thing, however, file attributes are not standardized in
either their use or implementation. So, the least common denomitor
seems to be embedding this metadata into the file name, then having
the application decipher it and Do The Right Thing(tm).
[2] Note, this convention doesn't break on Windows, nor does it
break Windows. It breaks certain applications used on Windows. So,
the blame can't even be placed on the OS, which, though
inherently different from UNIX, doesn't seem to mind file names with
dots them. The real blame lies with those who decided to make it
a blanket policy to disallow anything with dots in the file name
rather than testing for paths with */../* and/or */./*, etc.
--
Seeya,
Paul
GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 20:11:45 2003