On Oct 2, 2007, at 9:18 AM, 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.
As a long time (1984'ish) Mac only developer and an svn user, I'm
going to chime in here Steve. You really are reading way too much
into the responses you are getting. The svn developers are relatively
Mac friendly, there is no need to poke them in the eye.
The responses mean exactly what they say: the features you are asking
for just don't exist yet. It's not because of malice, there just are
a limited number of developers and features like these are not a high
priority.
However, svn is open source, so if you can come up with a generic
implementation and code it they would probably take your changes. I
would like to see those features in svn and I would like to see a
solution to the package problem too (also not Mac specific, a recent
note in the feature request indicates it's badly needed by Ruby
developers as well). But since I don't have the time to code it
myself, I'm not going to rail on the developers for not working on
what is important to only a minority of the svn users.
>> 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.
You'll notice they aren't supported either. :-) And it's probably not
because the svn developers hate Windows (though I wouldn't hold it
against them if they did).
> 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.
I would disagree here. I'd say most of "us" solved it by not using
resource forks anymore. They are increasingly difficult to use in the
modern world and their functionality can be obtained with more
external-filesystem friendly solutions these days. However, that
doesn't really help anyone who has to support legacy code, which is a
reality for many Mac developers.
>> 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)
Well, then propose an implementation and code it.
Off of the top of my head, you'll want to address the following
important issues:
- Need to be able to svn diff encoded source files with the server
(e.g. if a .c file is encoded, the user still needs to be able to svn
diff with any revision from the server and see the text changes).
- Document what the performance tradeoff will be when just a bit of
meta-data or a resource changes in a file (e.g. if I change something
not in the data fork, how much re-encoding has to happen and how much
extra data will need to be transmitted and saved as a delta on the
server. With MacBinary that might be the entire file.)
- How does a Windows or Linux user decode files that have been
encoded? The need does arise believe it or not. Do all the clients
need to support all the encodings? Can they check out just the data
fork by default? What happens when they check changes in?
- The solution can't be Mac only. A Mac only solution means someone
needs to actively maintain the code as the client source base moves
forward, otherwise the Mac build will eventually be broken. Based on
previous postings, I'm not sure the devs would accept a platform
specific feature in the main source base, but I could be wrong.
> 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).
I was in on that argument. What a mess...
>> 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.
I would be happy to contribute and review ideas for platform agnostic
solutions to the encoding and package problems. I just don't have
time to dig into the svn code and attempt to implement anything. I
have too many other work things to deal with. :-)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 17:06:03 2007