Garrett,
The major problem I have with this sort of approach, as well as any
approach involving using an archiving and unarchiving wrapper, is that
I deal with tens of thousands of files that would be affected and I'm
afraid the processing time would be prohibitive. In addition, it truly
seems to me that Subversion would have more to gain by supporting
resource fork data natively than by requiring the users to implement
an undocumented workaround in order to fake it.
As far as I can tell, at least twice have developers stepped up with
patches (or the desire, capability, and willingness to create patches)
to the subversion project to handle this support -- Scott Collins of
MacCVSPro in 2003 and Frierich Munch in 2005. Both times the proposals
were shot down, most vocally by Brian Fitzpatrick.
Brian's main two objections have been that:
1. Resource forks are platform-specific.
2. Apple's stance on RF is that developers should move away from using them.
My objections to the objections:
1. The Macintosh userbase continues to grow, and as Subversion matures
as a project (congrats on the 1.4 release) it would be beneficial to
take a proactive stance on cross-platform support.
2. Apple's decision to deprecate resource forks happened when?
Pre-2003? It's 2006 now and resource forks are still in wide use. One
good example of indisposable resource fork use is Macintosh PostScript
font files, of which I maintain a development repository of tens of
thousands. If the resource fork is stripped from a Mac Postscript
font, the file is useless. The backbone of the Mac userbase is a
community of designers who have each invested thousands of dollars in
fonts, most traditionally in the Mac PS format. Does anyone think that
the Mac is likely to discontinue support of PostScript fonts in the
next 5 years? 10? Font designers and developers make up a sizable
community, all of whom would benefit from using subversion to maintain
version control of their projects. As would software developers who
bundle fonts with their applications.
Is the subversion developers' official stance still that resource fork
support is not a desired feature?
I've also noticed that some related threads in the past have morphed
into a discussion of xattr support. I may not be understanding the
conversations correctly, but is it the case that implementing xattr
support would both add a beneficial, forward-thinking cross-platform
feature and simulateously have the side benefit of Mac resource fork
support?
Thank you again,
-Danny
On 9/19/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 9/18/06, Danny Dawson <danny@quasistoic.org> wrote:
> > Dev-List,
> >
> > There was some discussion last year about supporting Mac-specific
> > resource fork data in subversion, which morphed into a discussion
> > about xattr support, and I can't quite figure out if there was some
> > kind of resolution that resulted from this discussion. Could you
> > enlighten me? Is there a way to use subversion to track development of
> > files with crucial data in the resource fork, or was this never
> > implemented?
> >
> > The discussion I'm referring to seems to have originated here:
> > http://svn.haxx.se/dev/archive-2005-08/0523.shtml
>
> It's never been implemented, so at the moment you'd have to use a tool
> to write the resource fork into a file that can be versioned (I
> believe Apple has tools that do this, although I've never actually had
> to care about resource forks, so the details are beyond me).
>
> -garrett
>
--
Danny Dawson
http://quasistoic.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 19:25:39 2006