[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moving working copy metadata

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-04-16 12:54:54 CEST

On Apr 16, 2007, at 05:27, Ulrich Eckhardt wrote:

> On Friday 13 April 2007 22:34, Matt Pounsett wrote:
>> Mac OS is now using a new structure to replace the old Resource Fork
>> of a file which was used in the old HFS days. In place of a file
>> with a Data Fork and Resource Fork, you now may have a directory
>> structure where the top level is presented as a "File" to the user,
>> and lower levels contain various discrete elements of the data. One
>> such implementation is used for the data files of Keynote, a
>> presentation competitor for Powerpoint.
>> Adding Keynote files to Subversion repositories without wrapping them
>> in some way first (zip file, ISO or DMG image, etc.) is, basically,
>> impossible. Once an 'svn add' has been done on the directory
>> structure which is the document, the document is no longer readable
>> by Keynote.
>> The first solution that comes to mind, for me, is having a way to
>> alter certain working copies so that the .svn meta-data is stored out
>> of the way somewhere... perhaps within a dot-dir in the user's home
>> directory. Has any thought been given to having something like this
>> available as an option at checkout time?
> My first solution would be to fix the tool that barfs on those .svn
> dirs. Have
> you filed a bug report with the vendor? After all, Subversion is
> rather
> popular and not being able to interact with it might cost customers.

What would be great is if we could say to Apple, "Hey, these various
apps of yours don't work with Subversion because you clobber the .svn
directories in your document bundles when you save. You could either
change all your apps, or instead implement opaque collections in
Subversion and then nobody would have the issue ever again with any
app." I know I would vote for spending time on the latter in
preference to the former. I think it's pretty well defined how opaque
collections should behave. It just remains for someone to code it.

To reply to the mailing list, please use your mailer's Reply To All  
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 16 12:55:21 2007

This is an archived mail posted to the Subversion Users mailing list.