At 5:00 PM +0200 10/3/07, Brian W. Fitzpatrick wrote:
>Storing more than 64kb in a Subversion property is going to cause
>performance problems.
That's useful information -- basically it means that we want to
include AppleSingle support for files which have lots of resource
data.
This matches usage pretty well:
Files that have a data fork that is of use on other platforms (the
reason for using AppleDouble) tend to have very little or no resource
data. Therefore this limit is unlikely to be hit.
Files that have a lot of resource data, tend to be essentially binary
and are of no interest on other platforms, therefore AppleSingle
encoding is appropriate and this limit will not be relevant.
Files that have no resource data have a very small AppleDouble header
file (just the extended file attributes, etc.)
>Having arbitrary properties run client side scripts is a security hole
>big enough to drive a truck through.
OK -- we can avoid this by simply implementing the encodings in the
Mac OS svn client for now.
>Why can't you just use Rez ad DeRez again? You don't "lose" old
>versions unless you totally nuke your CVS repository.
Efficiency: in files that have a lot of resource data, that data tend
to be binary (graphics, icons, sounds, etc.) -- storing them as an
ASCII hexadecimal dump is rather inefficient.
Effort: This requires a lot of manual effort, plus modifications to
the build procedures for every project.
Also, this still doesn't address the non-resource Mac OS file
attributes that are lost (file type, creator, finder comments,
creation date, etc.)
>Just how many Mac developers out there have this "critical need" and
>how does the above described feature help non Mac-developers?
Anyone with existing code.
In the Mac programmers lists I frequent, not being able to to store
mac files (and not providing as an escape) has left svn as a nice toy
to try on a new project when I don't have to preserve existing code.
In the user front, svn doesn't handle Mac file types or other
standard attributes, bundles, etc. -- most Mac file attributes are
lost.
There are plenty of existing file formats that use resources, for
instance most graphics packages create custom thumbnail icons for
images which are stored as resources in a JPEG file.
>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.
Deprecated and not currently in use are two different concepts.
Further you have to realize that there are multiple political camps
at Apple -- notably the Mac OS / NeXT split. The nexties have been
trying to deprecate the Carbon API in favor of Cocoa for years, but
most major commercial applications (including the Mac OS Finder and
iTunes) are Carbon -- as is Photoshop, Microsoft Office, etc.
(A friend at Apple once suggested to best way to model Apple is a
self-contained venture capital firm with 100 little start-ups all
fighting for funding)
As far a the number of developers, by not providing proper support
for the existing Mac OS file system in svn, you have self-selected
the Mac developer community out of the subversion community.
Most that I know have evaluated svn and either stuck with CVS or
moved on to Perforce.
Now with Perforce jacking up their licensing fees and imposing
ridiculous policies, there are a bunch examining svn again to see if
it's ready for prime time.
I've been wanting to use it myself for several years (and have been
using it on a smaller project with a subset of my source tree for 9
months), but its inability to hold my existing source base without
significant modification to hundreds of files has been a barrier.
>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).
At the moment, it affects a lot more people than you realize (they
have gone on to other products or deferred adoption until they can
start a fresh project with no legacy code) and there is no practical
workaround (you are still focusing on resource forks rather than
losslessly representing Mac OS files).
Subversion is extremely close to being a useable product, but this is
a deal breaker for most commercial developers because we can't import
our existing code and be sure that we haven't lost data.
Neither can users store an arbitrary file and be sure that it is all
there on checkout.
HTH,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 23:02:56 2007