I have a question regarding best practices when using Subversion with
Mac OS X, particularly as related to the Mac's use of "packages".
=Background=
Mac OS X and some Mac Apps use "packages" in the file system to store
content. These are really just directories with known extensions that
Finder "pretends" are normal files. For example, Mac apps are supplied
as folder trees where the top-level folder has a ".app" extension. When
applications use packages to store documents, Subversion can get very
confused.
=Problem=
Consider the drawing application OmniGraffle, which stores drawings in
packages with an extension of ".graffle". Create a drawing and save it
as "foo.graffle". Remember, this isn't a normal file: it's a directory
that contains files, it just looks like a file in Finder.
Add this drawing to an SVN repository. This works fine, *however* at
this stage SVN creates its normal hidden ".svn" directory _inside_ the
package, since as far as it is concerned, this is a normal directory,
not a package.
Now update the drawing in OmniGraffle and save it. One of three things
will now happen depending upon the application:
(1) The application will update the _contents_ of the package, but not
touch the package directory itself. This is compatible with SVN and
causes no problems. However, I'm not aware of any Mac app that behaves
this way (nor should any, since its potentially unsafe).
(2) The application sees the ".svn" hidden directory in the package and
panics, since it cannot understand this. I think a good app should do
this, but again I'm not aware of any that do.
(3) The application creates a new temporary package, saves the updated
drawing to that location, then deletes the old package and renames the
new package to the final save name (foo.graffle). Most apps I'm aware of
use this approach.
Option (3) is the problem. A side-effect of saving the file in this way
is the elimination of the ".svn" folder created by SVN. This, of course,
confuses SVN no end when it comes to a later commit.
=Solutions=
I can see several possible work-arounds for this, and was looking for
feedback on what others (if any) do under these circumstances (other
than "use Linux instead", hehe).
(1) Edit and save in a temporary directory outside of the SVN working
copy, then hand patch the changes back into the package. This approach
seems to me rather fragile.
(2) Edit and save in a temporary directory, then wrap the package into a
real file, such as a ZIP, DMG or TAR, and check that into SVN. This
would work, but is rather labor intensive.
(3) Find some magic SVN command that would rebuild the .svn directory
without disturbing the updated content inside the package (which is now
different from the HEAD revision, remember).
#3 would seem best, but I have yet to find that magic command. Anyone
any ideas? Am I missing something obvious here?
Any input greatly appreciated.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 1 21:17:06 2006