[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: experiment to get Mac resource-forks under version control [with PATCH]

From: Nicholas Riley <njriley_at_uiuc.edu>
Date: 2003-05-14 08:50:53 CEST

On Wed, May 14, 2003 at 02:32:49AM -0400, Scott Collins wrote:
>
> Do I absolutely need it? No. I already have these projects with
> resources in CVS. I have a visual CVS client (MacCVS Pro, I'm one of
> the authors, this is one of the things that came out of our work on
> Mozilla)
>
> <http://sourceforge.net/projects/maccvspro/>

MacCVS Pro is about the only thing I miss about CVS when using
Subversion :-)

> Deprecated exactly the way Carbon is deprecated, that is, the Next
> people who now run Apple hope it will go away, but real developers end
> up still needing it. I've been working on cross-platform projects for
> the past 12 years---most recently as one of the principal developers of
> Mozilla, and a member of mozilla.org staff---and a lot of things about
> Apple's development strategy leave me totally cold. I'm sort-of
> playing the devil's advocate here, but your point is well taken. I've
> only needed resource files recently as part of a Palm project I'm
> working on.

I feel the same way, FWIW. We need more metadata, not less. If it
has to be implemented in a not-so-nice way on foreign filesystems, so
be it. Other Unixes and Windows are moving towards extended
attributes in -their- native filesystems (in the case of NTFS, it
already exists), which Subversion will need to support eventually - so
it won't be a permanent discontinuity. And the fact is, simply, that
many components written since the release of OS X use resource forks
for metadata. The "all the world's UFS" mentality is backwards-thinking.

> Yeah, I've been thinking about that. I have a question with respect to
> that. Is the opaque collection really a source object? Or is it
> better represented as a product of the build, that requires not much
> more than copying to produce? I'm thinking in terms of a Konfabulator
> Widget, for instance. You can manage all the source pieces in
> subversion, but only assemble the _actually_ opaque object as a product
> of your `build'. 707 and the discussion on this topic that I've
> managed to dig up don't give me enough of a feel for the problem to
> understand why this is a good reason to provide a mechanism for moving
> the subversion administration data outside a sub-tree of the working
> copy. Hopefully, you're the right person to fill in the blanks of my
> understanding :-)

Consider a RTFD document (bundle containing a RTF file and one or more
media objects), or a Keynote document (bundle containing an APXL file
and one or more media objects), or a Project Builder project or
Interface builder document. None of these are build products, but all
are opaque, and NS/CFBundle doesn't (and IMO shouldn't) try to
preserve dotfiles inside packages.

-- 
=Nicholas Riley <njriley_at_uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 08:51:43 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.