On Sep 22, 2005, at 20:58, Wilfredo Sánchez Vega wrote:
> Extended attributes are a well supported feature in Tiger which
> is not deprecated at all. Resource forks are a slightly different
> thing, but both are stored in ._ files.
Well, as you say, only on non-Mac-native filesystems. So, on HFS, HFS
+ and case-sensitive HFS+, the OS won't create any ._ files for you.
> Users should actively avoid storing ._ files in Subversion
> repositories directly. The behavior of these files is not the same
> on HFS+ as UFS, and it would not be prudent at all for Subversion
> to become knowledgeable about them other than to ignore them by
> default.
Actually, if Mac users want to store resource forks or extended
attributes in a repository right now, I don't see any reason why they
shouldn't check in the ._ files.
For example, on my Mac, I access a working copy that's on a Samba
share on a Linux server, so when my Mac creates resource forks on the
Samba share, it creates ._ files on the Linux server. I could check
these in, and they would work great when access over the Samba share
from a Mac.
If I were storing the working copy on my Mac locally, on my HFS+ hard
drive, then I would have to use /Developer/Tools/SplitForks to split
out the resource fork into a ._ file before checking in, and run /
System/Library/CoreServices/FixupResourceForks to recombine them
after checking out.
If people want to use resource forks in Subversion repositories
today, that would be one IMHO reasonable way to do it. Though, as I
mentioned yesterday in another thread, Rez / DeRez may make more
sense, depending maybe on the type of resource.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 23 12:22:00 2005