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.
> but don't see a good reason to muck up
> a new piece of software
I hope not to muck anything up. Your (et al) advice can help. But if
everyone agrees this idea is too stupid to waste their time on, then I
guess it won't have enough gas to be a learning vehicle for me.
> 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. 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.
> -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 :-)
Thanks for taking the time to reply,
__________
Scott Collins <http://ScottCollins.net/>
- application/pgp-signature attachment: PGP.sig
Received on Wed May 14 08:35:06 2003