Matt Pounsett-2 wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> I'm starting to run into a problem adding some documents to
> Subversion which is becoming more and more common. The problem stems
> from having situations where directory structure is an integral part
> of the data, and adding .svn directories at each level is tantamount
> to corruption of the data. I think I've checked everywhere in
> Subversion for a solution, but haven't found anything yet, so I
> thought I'd ask to see if anyone else is starting to see this issue,
> and if anyone has found or considered solutions.
> Since I've probably completely confused anyone who hasn't seen this
> before, an example:
> 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.
It's not a perfect solution, but the following bash function will restore a
svn directory that's been borked by an apple app:
mv $1 "$1-backup"
svn up $1
rsync -arC "$1-backup/" $1/
svn add --force $1
rm -rf $1-backup
(note that there's no trailing /)
View this message in context: http://www.nabble.com/Moving-working-copy-metadata-tf3573794.html#a10166154
Sent from the Subversion Users mailing list archive at Nabble.com.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Apr 24 19:58:19 2007