On 10/3/07, Steve Sisak <sgs@codewell.com> wrote:
> Given that these are file system encodings, it's
> probably reasonable to implement them directly in
> the svn client and defer discussion of a general
> MIME type handling architecture for a 2nd pass --
> nothing precludes pulling the code out into a
> wrapper at a later time once an architecture has
> been designed.
>
> Note that, while I've define everything needed
> for Mac OS (because there's a critical need),
> there's nothing here that's platform-specific in
> that all that is needed is to provide a platform
> property equivalent equivalent to
> file:appledouble an define its contents. This
> just happens to have already fully defined for
> Mac OS for over a decade.
>
> There, done. Any holes?
Comments:
Storing more than 64kb in a Subversion property is going to cause
performance problems.
Having arbitrary properties run client side scripts is a security hole
big enough to drive a truck through.
Questions:
Why can't you just use Rez ad DeRez again? You don't "lose" old
versions unless you totally nuke your CVS repository.
Just how many Mac developers out there have this "critical need" and
how does the above described feature help non Mac-developers?
And lastly:
My main concern here is that this seems like an awful lot of code
churn for a feature that is needed for a feature (resource forks) that
Apple has deprecated and that affects a microscopic number of people.
I understand that this is an inconvenience, but I'm always hesitant to
add a feature for something that 1) affects very few people and 2) has
a workaround (ie Rez and DeRez).
-Fitz
PS Interesting tar wrappers fun:
http://svn.haxx.se/dev/archive-2003-02/1485.shtml
PPS Total disclosure: I used to work at Apple
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 17:00:41 2007