Is this considered safe?

[Brian Postow <bp...@gmail.com>]

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.

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?

Thanks

Brian Postow

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1303224

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Is this considered safe?

[Toby Thain <to...@telegraphics.com.au>]

On 11-Mar-09, at 12:07 AM, Ryan Schmidt wrote:

> 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, ...
> There are two alternatives you might want to consider instead of what
> you're currently planning:
>
> 1. Stop using resource forks, if possible. ...
>
> 2. Put the resource forks into the repository. ...

There's an even better way: Use the .r text format for resources.

This gives a human readable view of most system resources, and a hex  
dump for others, which is fully diffable.

See the Rez utility in the Apple Developer tools (this is also  
available in MPW and CodeWarrior).


>
> Either of these options require manual intervention from you before
> and after every commit (compress, commit, decompress; or AppleDouble-
> encode, commit, AppleDouble-decode).

Compile them to resource forks as a build step, either in a Makefile,  
or an Xcode project (Xcode knows about .r files).

--Toby


>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do? 
> dsForumId=1065&dsMessageId=1306211
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe@subversion.tigris.org].

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1327222

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Is this considered safe?

[Ryan Schmidt <su...@ryandesign.com>]

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@subversion.tigris.org].