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

Re: Mac OS X "packages" Best Practices?

From: Mike Conley <nomad_at_crystalmaker.com>
Date: 2006-03-03 10:27:58 CET

On 02.03.2006, at 20.08 (UTC-0800), Dave Camp scribbled thusly:

>I contend that applications that do not respect extra contents added
>to a bundle are equally at fault. When Pages (as an example) saves
>the open document, it blows away any additional files that were in
>the in the document bundle instead of preserving them.

You're placing the burden of support on the wrong shoulders. I don't see that other applications/processes have any business adding data to another application's bundle; if they do, it's not the target application's fault for failing to notice or respect said data.

If Subversion went about tacking extra crap onto the end of every file under its control as a means of tracking changes, applications would be no more responsible for blowing those data away than they are for losing the .svn directory when they make changes to bundles. Bundles are, except to the application that created them and to the OS, an atomic structure under Mac OS X, and are not to be toyed with by other components. There are APIs for examining and extracting information about bundles; they are not to be treated as directories, as it's entirely possible (though, admittedly, unlikely) that this structure could change in the future.

The solution is to modify SVN so that the owner of a repository can tag a particular directory as being opaque; SVN would then be required to treat the target directory as it would a file and maintain state information in its enclosing directory. This solves the problem without making it Mac-specific; this would be generic, would work on any OS, and would be useful to other than Mac users as well.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 3 10:30:34 2006

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