At 2:09 AM -0400 8/11/08, Karl Fogel wrote:
>Matt Slot <fprefect_at_ambrosiasw.com> writes:
>> The data is in a standardized and supported format, so it should be
>> forward compatible. It's also "optional", in that platforms which
>> don't recognize Mac resource forks won't be affected, nor will older
>> subversion releases.
>
>The sole and only issue here, as far as I can see, is the additional
>complexity this would put in the Subversion core code. We'll have to
>maintain it, and naturally are a little reluctant. It's not that the
>patch is bad, nor the feature undesirable. It's just a question of
>overall cost/benefit (yes, I understand that the benefit for Mac
>developers is huge, but that's still a subset of all users).
Understood -- although there may be a cause-effect relationship
between the number of Mac OS "users" of svn and its inability to
handle entire files without each user having to modify/patch/wrap svn.
(As a 20 yr commercial software developer, the complexity of doing
this has just left me using cvs, which sucks but works)
>I do wonder if, instead of maintaining a custom patch, it might make
>more sense to maintain a script that wraps svn and DTRT with such
>bundled directories.
Just to be clear, we're not talking about bundled directories
(bundles) here -- bundles being littered with .svn directories is a
completely separate can of worms -- we're talking solely about being
able to round-trip single files intact.
Just to add some background information:
The notion that Mac OS files are somehow nested directories is a
common misconception among unix and Windows developers.
"Traditional" Mac files have a data fork (single stream) and a
resource fork (structured data) plus a fixed set of attributes that
go beyond what POSIX offers (type, creator, creation date, etc.)
<http://developer.apple.com/documentation/mac/Files/Files-14.html>
<http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/Reference/reference.html>
this is the case that's most likely to currently exist.
"Modern" Mac OS files have an arbitrary number of streams/forks any
of which can be structured or flat and an arbitrary number of
extended attributes (accessed via the xattr command). There are
standard names for the data fork and resource fork. (IIRC, NTFS has
the same concepts, but I don't do Windows)
Multiple forks and attributes are supported directly by HFS, HFS+,
ZFS, NTFS and faked by the OS (usually using AppleDouble) on file
systems that don't support metadata (UFS, FAT32). That "._" file that
the unix folks despise is an AppleDouble file, not a resource fork --
although it might contain a resource fork if the file had one.
<http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/io_porting/chapter_8_section_2.html#//apple_ref/doc/uid/TP40002854-TPXREF124>
<http://developer.apple.com/documentation/Carbon/Reference/File_Manager/Reference/reference.html#//apple_ref/doc/c_ref/FSOpenFork>
<http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getxattr.2.html>
<http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html>
Google "site:developer.apple.com extended attribute"
"Bundles" are a NeXT concept to store structured data in a tree of
directories instead of structured files in order to make them more
palatable to unix developer tools and then use a bit in the directory
permissions to present the bundled directory as a single file to the
the user.
<http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Concepts/about.html>
The issue with svn and bundles is that a bundle checked into svn
becomes littered with .svn directories which become part of the
bundle on checkout -- this is a separate issue not addressed here.
(For bundles that are part of a build process, this requires copying
and stripping the bundle as a separate build step which, fortunately,
can be automated)
A general solution would support an arbitrary number of streams/forks
per file, possibly with structure within a stream as do the current
Mac OS and Windows API's and not litter bundles with scm-created
directories.
Matt's patch only attempts to address the first issue: the ability to
round-trip single files without losing Mac OS specific metadata. But
this is the only common case with existing repositories -- new code
can be warped into svn's model.
>it's also not very inconvenient (for me, anyway,
>though of course I'm overly familiar with my version control tools,
>relative to most users).
Bing! :-)
Cheers,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-11 15:08:09 CEST