Scott Collins <scc@ScottCollins.net> writes:
> On Wednesday, May 14, 2003, at 12:49 AM, B. W. Fitzpatrick wrote:
>
> > Considering that even Apple is discouraging the use of resource forks
> > in the future, I am -1 on putting this Mac OS X specific feature into
> > Subversion. Is there any reason (aside from the inconvenience) that
> > you couldn't use /Developer/Tools/DeRez when you stuff the resource
> > fork into your Subversion repository, and /Developer/Tools/Rez when
> > you pull it out?
>
> 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 handles it just fine. It would be convenient for me if
> subversion could do this, but it's only an inconvenience that it
> doesn't. Perhaps my patch, even after it's mature, will never become a
> part of the released subversion. Still, it would be nice if I could
> build a client that supported this facility even if just for me and the
> people participating in a project that needed it. My intention was to
> implement it in a way that would be as non-intrusive as possible. Even
> if _this_ idea doesn't go into subversion (as it probably won't)
> developing this feature to a working state will bring me up to speed on
> subversion standards, politics, policy, and architecture... that is if
> people with knowledge look at the code instead of dismissing it out of
> hand ;-) I've been lurking on the list for quite a while; but there's
> nothing like actually writing code.
Understood.
> > with a feature to support something that is a)
> > platform specific, and b) deprecated.
>
> 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.
Support for Carbon is likely to continue for many years--I don't see
how Mac OS X could really live without it.
...<snip>
> > -Fitz, certain that someone, somewhere is going to turn the above
> > paragraph around on him to shoot down the whole opaque collections
> > thing at some point in the future.
>
> 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 :-)
For details on opaque collections, see bug 707:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
-Fitz
--
Brian W. Fitzpatrick <fitz_at_red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 16:04:37 2003