On Mar 10, 2009, at 09:11, Brian Postow wrote:
> I have a subversion repository, and everything works fine. EXCEPT
> that svn doesn't seem to work correctly with Macintosh resource
> files, or actually, anything with resource fork. It just zeros it
> out and gives only the data fork. For resource files, this is a
> major problem.
Yes, Subversion doesn't know anything about Mac-specific resource
forks, has no code to read them, and will ignore them, thus causing
them to be lost when importing into Subversion.
> So we solved this by taking our resources out of the repository.
> Fine. However, we still want a central place to keep/ exchange/
> backup our resources, and other files that have resource forks.
> We'd like it to be in the same place as the repository, just so we
> can keep track of it. What I would LIKE to do is add a folder into
> the top-level folder of the repository, the one with the dav, db,
> conf folders etc. and stick the stuff there.
>
> I understand that svn won't do anything useful with these files. I
> just want to know if this will confuse svn, and make something
> break, or will subversion just ignore the extra folder, like I want?
>
> So, is it safe to create this folder?
You should not create any other files or directories inside a
Subversion repository directory (the directory containing README.txt,
conf, dav, db, etc.). Subversion will ignore it but if ever in the
future you want to dump and load the repository in order to take
advantage of performance enhancements in some future version of
Subversion, you would have to remember to move any of your additions.
If you ever bring in any other sysadmins, they would have to be made
aware of this unusual addition. Basically, any other location on your
server's hard drive would be a better choice than putting nonstandard
items into the repository directory.
There are two alternatives you might want to consider instead of what
you're currently planning:
1. Stop using resource forks, if possible. They've been deprecated
for years, though I realize there are still some places where
resource forks cannot be avoided. And if you're trying to archive
legacy files, then of course that won't work either.
2. Put the resource forks into the repository. There are a couple
ways you could do this.
2a. You could zip or stuff the files before putting them in the
repository. This wouldn't be efficient since compressed files diff
poorly. But it would at least work.
2b. Instead of compressing, split the data and resource forks, e.g.
using the AppleDouble format. This way at least the data fork portion
would be diffable (if it's a text format).
Either of these options require manual intervention from you before
and after every commit (compress, commit, decompress; or AppleDouble-
encode, commit, AppleDouble-decode).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1306211
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-11 05:08:26 CET