On 13 Apr 2007, at 21:34, Matt Pounsett wrote:
>
> 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.
>
> 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?
>
> I'd be interested in hearing other people's thoughts and
> experiences with this issue.
>
> Matt
Yes. Matt, I posted to this list on the same day as you with the
same problem, only with WebObjects Builder.app! In my experience
WebObjects Builder.app and Keynote.app don't preserve the working
copy administration area directory (.svn), but its presence doesn't
interfere with the operation of these applications. The svn command
line tool recreates the .svn directory in such a way that 'svn
status' doesn't report changes for files you know you have changed.
Do we like Terminal.app and shellscript?
Place this in ~/bin/wcaa.sh .
Check out a project, cd to your working copy, then run wcaa.sh. This
will recursively search your working copy, making a single zipfile
containing any .svn directories it finds, and writing a shellscript
wcaa-restore.sh . After editing with Keynote (or pretty much any
modern moderately full-featured MacOSX document-orientated
application), you run wcaa-restore.sh to recreate any missing .svn
directories from the zip archive if their parent directory still
exists. You can then use 'svn' as normal.
Matt, if you really are having problems caused by the presence
of .svn directories, try
% svn checkout ...
% wcaa.sh
% find . -type d -name .svn -print -prune -exec rm -rf {} \;
[edit with Keynote]
% ./wcaa-restore.sh
% svn ...
--
Patrick Middleton
OneStep Solutions plc
351 London Road Phone: +44 (0)1702 426400
Hadleigh Fax: +44 (0)1702 556855
Essex. SS7 2BT Email: patrick@OneStep.co.uk
England (MIME welcome)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
- application/octet-stream attachment: wcaa.sh
Received on Mon Apr 16 13:02:11 2007