Well, we have two discussion points here, I think...
(1) The design of the bundle/package system in Mac OS X.
(2) If and how Subversion should handle this issue.
<editorial>
(1) There is no doubt of a need for structured storage *within* the
user-paradigm of a "file". There are really two options: (a)
standardized file formats or (b) folders-as-files. Both extend the
directory tree "into" the file, but each from an opposite perspective.
Microsoft chose the (a) approach with structured storage (i.e. OLE
documents), and so did OpenDoc, which are really ZIP files (as, for that
matter, are Java JAR files). Apple chose (b). There are pros and cons to
both models. (a) offers a more consistent "view", since only apps that
known how to crack open the file do so. The flip side is that a lack of
standards makes tool development harder: consider search issues. (b)
enforces a consistent model and leverages the file system code to also
provide the "interior" view (a significant advantage, imho). But it's
too easy for tools to "miss" the folder decoration and damage the package.
Regardless of merits, I think Apple made a big mistake with the design
of their folders-as-files solution, since they distinguish regular
folders from "bundles" by the extension to the folder. For example,
"foo.app" is an application bundle by virtue of its ".app" extension
_and nothing else_. This is a mistake, since it means one has to know
the list of extensions that mark folders as bundles. (There is also a
"bundle" bit, but this is not the _only_ mechanism). It means, for
example, that any Subversion solution to this problem has to handle a
lot of Mac behavior in order to make sense of this. If the only
mechanism was the "bundle" bit in the folder,
</editorial>
(2) How can Subversion handle this?
(a) Ignore it. The issue was opened in 2002, with no comment for 24
months. I would assert therefore that this is indeed what is happening.
Presumably this is considered low priority, though I'm surprised by this.
(b) Publish a work-around. I have decided for the time being to wrap all
packages into ZIP files before checkin. This is painful, but do-able and
does sort of work. Of course, DIFFs are out, but its better than
nothing. Putting some discussion of this in the SVN book might be a good
idea.
(c) Design a fix. I'm happy to look into the design of such a feature
and start the necessary discussions, though I simply don't have the
bandwidth to develop a patch right now.
Thoughts, anyone?
--Tim
Aaron Montgomery wrote:
>
> On Mar 2, 2006, at 10:09 AM, Mike Conley wrote:
>
>> On 02.03.2006, at 09.56 (UTC-0800), Aaron Montgomery scribbled thusly:
>>
>>> Correct, but in the Mac OS X file system, a bundle is a directory.
>>> If the developer wants the document to be treated as a single opaque
>>> object in the file system, he/she needs to create a file, not a
>>> directory. If the developer creates a directory, he/she should allow
>>> that directory to be treated like a directory.
>>
>> Sorry, no, that's not the way Mac OS X works. Bundles are integral to
>> the way applications are packaged and store data now, and they are
>> intended to be opaque to the user. The Finder maintains this illusion
>> (although it also allows a means by which the user can see inside the
>> bundle if he really wants to).
>
> You cannot get around that they are directories, whether or not the
> Finder presents them as files. In fact, the first line of Apple's "The
> Bundle Programming Guide" is pretty explicit about them being
> directories: "A bundle is a directory in the file system that groups
> related resources together in one place." Admittedly, if it is a
> package, it is supposed to be presented as an opaque object to users.
> Unfortunately, it is clear from how they are treated in the Terminal
> and through File Systems calls, that "users" refers to people working
> through the Finder.
>
> I didn't say that it wouldn't be nice if SVN allowed directories and
> their contents to be treated as opaque binary objects (although this
> could get tricky to program, which might be why they haven't done it).
> All I said was that allowing svn subfolders was a reasonable feature
> request that the developer may or may not be able to accommodate. The
> developer may not even be aware that there is a problem with their
> bundle structure, it may be an easy fix, and the change would allow
> the developer's documents to play nice with CVS, SVN and any other
> UNIX program that treats directories like directories. If the
> developer is aware of the problem but it is a difficult to fix, then
> they might not fix it, but that doesn't make the request unreasonable,
> just one that cannot be accommodated. If your current problem really
> is just OmniGraffle, I've always found the Omni Group to be reasonably
> accommodating. Even if they cannot fix it, the worst they will do is
> nicely tell you that it just cannot be done.
>
> Asking the developer also seems like the most practical avenue at this
> point, since it is unlikely SVN programmers are going to rush out and
> fix this (it has been years since it was reported); and also unlikely
> that Apple is going to fix this (they adjusted their own code to
> handle svn folders in nib files).
>
> It was just a suggestion that might have helped you solve your
> immediate problem, take it or leave it.
>
> Aaron
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 2 22:45:14 2006