Re: Subversion wrappers (was: cvs 1.10 vs 1.11)
Re: Subversion wrappers (was: cvs 1.10 vs 1.11)
- Subject: Re: Subversion wrappers (was: cvs 1.10 vs 1.11)
- From: j o a r <email@hidden>
- Date: Fri, 29 Dec 2006 22:39:17 +0100
On Dec 29, 2006, at 9:39 PM, Sean McBride wrote:
To place an example where svn is inferior to cvs, I stuff documents
made with Pages.app into a svn repository to get version control.
Often, Pages liberately removes the .svn directory inside the
document bundle.
TextEdit does the same with .rtfd documents. Xcode and IB however
seem
to be written more carefully, they do not blow away the .svn folder
within .xcodeproj and .nib files. Please do file (duplicate) bugs on
this issue!
I think that bundles are brilliant - and one of the great unique
technologies of Mac OS X! The ability to use a regular directory to
store various resources for an application, a framework, or like in
this case a file. It's genius.
But I don't think it's clear cut what is the correct behaviour in
this case. I think that an application that has defined its own
bundled file format can consider the contents of that file package to
be "private", and to expect that it (and possibly associated helpers
like spotlight importers) is the only one who has the right to access
its contents directly.
For apps like Xcode and IB it makes sense to be prepared to honour
the presence of CVS or SVN files inside their file packages, but
should this also be imposed as a requirement for bundled files in
general? That you need to handle unknown stuff inside "your" file
packages, and that you would have to know how to support / maintain
these extra files / folders when updating your own file contents?
Consider the typical problematic case of an atomic write, where you
create a new file, and replace the old file if the new file was
created successfully. Should all applications that deals with bundled
files be expected to not only manage their own file contents, but
also bother with attempting to copy over other miscellaneous stuff
from the old file before deleting it?
Perhaps this is all much easier than I make it out to be. I guess it
can probably be fixed by implementing the proper support to the file
management APIs in the high level frameworks (like NSFileWrapper)?
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden