<I just joined this list, and wasn't sure how to reply to the original
thread about issues with Mac resource forks and file meta data>
It seems like one (long term) solution to the issue would be to "add"
to the Mac OS Client.,
using a concept similar to file bundles--the data fork, resource fork,
and any future metadata could be split up using what subversion already
has--text and binary comparisons. It would also allow storing on
non-metadata supporting file systems by saving the "file" as a
directory with sub files. That would also allow the saving of the file
name--the full unicode name could be stored in a separate sub file,
just in case the hosting file system (or even subversion) didn't
support unicode, long file names, etc. "All" it might take is to add a
wrapper functionality to the front-end (client). The client would
"intercept" downloads of special folders (maybe foldername.<some
extension>?), and convert them into one Mac file (doing "merges" and
"unmerges") It should be possible for the client to be smart enough to
update only the data fork or resource fork. The server would just see
normal file/folder traffic. It seems like the only piece that would
effect the overall subversion project would be in marking the file
bundle directory in some way that the client sw would know to merge it
that would be compatible with the normal subversion system…
mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 2 16:16:13 2004