On Oct 2, 2007, at 11:18, Steve Sisak wrote:
> 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.
Lots of discussion in this thread this morning. :) Just to clarify:
my intention in my first message was not to say "that's a Mac-
specific thing, Macs are stupid, Subversion won't do that." I'm a Mac
user of 17 years and counting, years ago I dabbled in the creation of
Mac applications, I understand resource forks and file/creator codes
and AppleDouble files and so forth. At this time, however, I do not
develop compiled applications, but web sites, and for that,
Subversion is fine. All I wanted to make sure you understand is that
Subversion does not at this time have any feature which will make it
easy for you to store file/creator codes or resource forks (or
analogous concepts on other filesystems) in the repository. It will
not automatically encode/decode macbinary or anything like that, and
there are no client-side hooks so you can't even easily implement it
yourself. (This is somewhat intentional... the Subversion devs feel,
I believe, that it's a) difficult to write hook scripts that are
guaranteed to run correctly regardless of the client OS, and b) it's
something of a security risk to allow the repository to run arbitrary
code on a client.) So your options are to either write a wrapper
script which you use on the client side which itself does the
encoding/decoding before committing/updating/checking out/exporting.
Or you dig in and heavily modify the Subversion source code. Or you
don't use Subversion. I just didn't want you to spend a lot of energy
searching for a feature that isn't there, spending a lot of time on a
tool that may not be right for you.
Note that Subversion supports Mac OS X fairly well (well, except
packages; see below). It just doesn't support Mac OS 9 and earlier.
Resource forks are very much a Mac OS 9 and earlier thing, and are
not recommended (by Apple) on Mac OS X. I'm sure you know that
already, and I'm sure you can't do anything about it since you have a
history of resource forks in your MacCVS repository that you'd like
to preserve. All I can say is that Subversion will require
significant work to handle this in a way that will make you happy, so
you'll either have to help with that work, or find another tool.
You had an earlier comment about how Subversion doesn't store file
permissions (except the execute bit) to show there are similar non-
Mac-specific issues. FYI, Subversion also does not store file
ownership. Of course, it would be hard for Subversion to set file
ownership on checkout or update or export unless it were running as
root, and there's of course no guarantee that a given user even
exists on another system where the files are checked out. And
finally, for Subversion's original intended use, that of versioning
source code text files, file ownership and permissions are not at all
relevant. So it seems fairly reasonable that Subversion does not
support versioning these elements of the file. You may want to
version these items if you are misusing Subversion as a system backup
tool, but there are other tools that are better-suited to that task,
for example even FSVS, which is based on Subversion ( http://
fsvs.tigris.org/ ).
>> 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.
I do recall now seeing a message from Matt Slot and recognizing his
name... Ah yes, here it is:
http://svn.haxx.se/users/archive-2007-08/0895.shtml
So, if there's a patch that implements the functionality that you
want, then super, you can apply and use that patch. I'm not sure why
it hasn't been considered for inclusion in Subversion proper. Someone
(probably Matt) should take that up on the dev list, if a discussion
about that has not yet taken place.
>> 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.
Support for Mac OS X packages (and similar concepts on other OSes) is
an existing feature request:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
Possibly this will become unnecessary or at least less inconvenient,
as I understand there's work to redesign the working copy format so
that .svn directories don't get littered everywhere. Alternately, if
the presence of .svn directories is your only concern, you could use
SVK, which integrates fine with Subversion repositories and already
uses a different working copy format today.
http://svk.bestpractical.com/
>> 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.
I also just wanted to add that I do think what you propose sounds
useful: a way for the client to encode a file before sending it to
the repo and decode it when getting it back. I'm not sure how it
would be implemented... either the client has to grow the ability to
do these encodings on its own, or a mechanism has to be built for
client-side hooks. I haven't looked at Matt's AppleDouble patch since
I'm not versioning data with resource forks at this time, so I don't
know how it works.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 00:51:50 2007