Hi John,
Thanks for the thoughtful reply.
At 10:16 AM -0400 10/2/07, John Peacock wrote:
>Steve Sisak wrote:
>>If it is the case, I'm trying to determine if the effort is worth
>>the time or if the effort will be rejected for religious/political
>>reason as seems to be the case whenever someone mumbles the phrase
>>"resource fork" in an svn forum.
>
>I think you are reading too much into this.
Not trying to, I figured I'd attempt to address the issue directly so
we could get on to a constructive discussion.
>The Subversion I use is extremely platform independent and has been
>since infancy.
That's what I've been hoping -- I just can't use it yet for my heavy
development as it doesn't handle my platform well and I'm trying to
fix that.
>You are stumbling over a design limitation that isn't easily
>cracked, but has been discussed a lot.
I'm not sure it's that hard to crack if you start with an open mind
and scope it correctly.
In my searches of the mailing lists (both dev and uses) these
discussions seem to degenerate into the Mac developers getting
shouted down and/or dismissed as "not cross platform" by people who
haven't taken the time to learn the difference between a resource
fork and an AppleDouble header file.
Matt Slott (Ambrosia Software) put a lot of effort into an
AppleDouble implementation that has been distributed widely in the
Mac developer community, but met with silence in the svn community.
>The reason that data-forks frequently comes up in these discussions
>is that the concept is unique to one OS, and is particularly hard to
>deal with in a platform independent way (oddly enough ;-).
Funny that. :-)
Actually NTFS supports arbitrary streams per file and has a stream
type for MacOS resource forks. HFS+ also supports arbitrary streams.
Hint: software that doesn't support all platforms isn't
cross-platform, although a lot of open-source developers tend to
redefine platform as "more than one flavor of unix" or "my platform
and Windows. The "cross platform" types tend to ignore and/or deride
platforms with capabilities that don't fit their code.
Most of us Mac developers (I've been writing commercial software for
over 20 years) have just solved the problems and moved on. We're
quite used to getting data through platforms that tend to destroy our
files w/o proper packaging.
In any case, see my last reply to Andy for a proposal (and feel free
to shoot holes in it).
>If you had discussed storing OpenOffice documents unzipped in the
>repository, you would have hit another nerve with similar needs, but
>this affects all platforms equally.
Thanks for the example -- I don't have a lot of experience with
OpenOffice, but it may be worth exploring.
I could also see a use for just having a "zip this directory and keep
the whole thing as a binary file" property.
Mac OS Packages (the "modern" replacement for resource files, which
are a directory with an attribute set that makes them look like a
single file to the user) become littered with invisible .svn
directories inside what is logically a single file.
>There is also a lot of interest in document-specific merge tools
>(think XML documents) that would also require both server and client
>support.
It sounds like it's actually time to _use_ the MIME type property in svn!
>>If I need to do the work, I'd be interested in knowing if there are
>>other problems that would be solved by a general client-side
>>mechanism to fix up files based on their MIME type and/or other svn
>>properties.
>
>You probably aren't seeing the other big issue - distribution of
>server resident configuration to clients - that normally leads to
>suggestions to use project specific wrappers.
Oh, I'm quite aware of it.
Having to keep project-specific MacCVS Pro configurations in sync for
7 years has been a perpetual thorn in my side, but it's necessary to
do my work.
Given that svn has MIME types and properties, I ought to be able to
set the appropriate proerties and get on with things.
>There are no client-side hooks, at least in part if not primarily,
>because Subversion hasn't yet grown a way to distribute metadata
>configuration from the server to the client, and no one [sane] wants
>to encode that magic handling in the client code for all eternity.
Agreed. Although platform-specific metadata properties would go a
long way to solving the problem, if combined support for those
properties in the client.
In the case of Mac OS -- supporting the 4 common encodings
(AppleSingle, AppleDouble, MacBinary, and BinHex) in the Mac OS
client would completely solve the problem -- all that is needed is to
set the MIME type property of the file correctly.
Mac users already how to do this -- it's amusing and perplexing that
the open source community finds the concept of an encoding so
complicated.
If the data fork of the file contains something that's useful to (and
might be edited on) other platforms but you want to maintain Mac OS
Attributes, use AppleDouble, otherwise use AppleSingle or MacBinary.
(It would be dumb to use BinHex in a repository, since it's a 7-bit
encoding, but it probably should be supported for completeness as
it's an option in MacCVS Pro and therefore might exist in existing
repositories)
>The discussion of server-managed configuration flares up every 8-9
>months for a while, but no one has produced a design that has gained
>wide support.
I agree that it's a hard problem in the general case.
>I personally view the server-side config feature as a necessary
>precondition to any implementation of client-side hooks.
Agreed.
However, making use of MIME types for well-known encodings and
defining standard properties for platform-specific file attributes
would go a long way without a huge amount of work.
Supporting these directly in the platform clients (i.e. the Mac OS
client supporting the standard Mac OS file encodings) would
accomplish the task w/o client side hooks -- it just kicks up the
"not cross platform" battle.
Either is an acceptable solution to my problem.
>You should really google the dev list for that topic,
I did (for "resource fork", AppleSingle, AppleDouble) -- the
discussion usually degenerated into "resource forks are evil because
they require twice as as many file operations (false, by the way,
since once a fork is open it's the same as any other file -- it just
has a defined structure).
>since I'm pretty sure that both data-fork and OOO docs came up at
>least a few times. In any case, any discussion of client-side hooks
>belongs on the dev list...
Thanks for the OOO idea -- that might be another piece of low-hanging
fruit -- especially as it gives another "cross platform" case that
might have a common solution.
It does look like it's time to move over to the developers list, but
I'm trying to follow proper etiquette and start on the users list to
se if there's an existing solution.
If there's anyone with experience with OOO documents and would like
to collaborate on a proposal (or could shoot me some relevant links),
please feel free to contact me off-list.
Best wishes,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 18:19:21 2007