Re: Moving working copy metadata

On Apr 13, 2007, at 15: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?

The request to allow Subversion to handle opaque document collections:

http://subversion.tigris.org/issues/show_bug.cgi?id=707

This would fix your issue.

The request to allow working copies without the pristine files in the
text-base:

http://subversion.tigris.org/issues/show_bug.cgi?id=525

This probably would not fix your issue as I suspect the .svn
directories would still remain, just with less content.

The request to allow the text-base to be compressed in working copies
to save space:

http://subversion.tigris.org/issues/show_bug.cgi?id=908

This probably wouldn't help either as the compressed data would still
remain.

You may also be interested in SVK, which is based on Subversion. I
understand that it does not use .svn directories to store its local
working copy data:

http://svk.bestpractical.com/

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org