Well put, and certainly hard to argue with.
I apologize for the tone of my email. I didn't intend to come across
offensively, but my frustration is certainly coming through. I work
with tens of thousands of files in dire need of version control, and
after switching to subversion from CVS a year ago for the rest of my
VCS needs, I don't really ever want to go back. Unfortunately, I also
can't seem to get the Mac Developer utilities Rez and DeRez to give me
anything but garbage, so I'm feeling helpless at the moment.
Thanks for your time and detailed response. I'll certainly report back
if I can find a workaround. Keep up the great work.
On 9/19/06, Garrett Rooney <firstname.lastname@example.org> wrote:
> On 9/19/06, Danny Dawson <email@example.com> wrote:
> > 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.
> Well, it's not undocumented if you send in a patch to the documentation ;-)
> > 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.
> I don't recall anyone showing up with patches, but you're right that
> before any patch arrives there really needs to be a consensus that the
> feature should be implemented. Personally, I don't see the benefit
> when compared to yet another bit of code to maintain, but then again,
> I don't use resource forks.
> > 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.
> We have a proactive stance on cross-platform support. The vast
> majority of our features are available on all platforms we support.
> Don't confuse "implementing a lot of platform specific stuff" with
> "being cross platform", as the two really aren't the same thing, and
> in fact are diametrically opposed to each other.
> > 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.
> Personally, I think it's unlikely that Apple will drop support for
> them any time soon, but I also don't think their use will increase,
> and I'd hope that people would listen to what Apple says and migrate
> away from them.
> > Is the subversion developers' official stance still that resource fork
> > support is not a desired feature?
> Look, you've gotta realize that this is an open source project,
> composed of many different individuals. We don't really have an
> "official stance" on anything, we generally have rough consensus on
> things, and that consensus may change over time. Historically our
> consensus on resource forks has basically been "not worth the effort".
> That could change given a nice proposal for how to implement it
> (looking at the svn:special stuff that was put in to support symlinks
> might be a good first step) and someone willing to do the actual work,
> but absent that it's unlikely that anyone is going to jump up and say
> "by golly we were wrong!" and just start coding.
> > 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?
> It would also mean a lot of complexity to support xattrs on the dozen
> or so filesystems that people use svn on in the real world. I'm not
> convinced it's worth the hassle.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Sep 19 22:55:27 2006