Argh. Honest, I was trying to resist...
On Tue, Feb 19, 2002 at 12:29:03PM -0600, Karl Fogel wrote:
> This is not a general solution to the problem, but then again, I've
> really only heard of this problem coming up regularly with the OS X
> interface builder anyway:
>
> I think they finally caved in and added special support to avoid
> clobbering CVS/ subdirs, and that they may be willing to do the same
> for Subversion, perhaps generalizing the support in some way so the
> problem doesn't keep coming up for future systems. Frankly, I'd
> prefer that to the burden of maintaining "verbatim directory" code in
> the Subversion client libraries...
Yes, there is code in IB to not stomp the CVS/ subdirectory, but this
really isn't the Right Thing. IB expects to have control of what it's
idea of a document is, and I don't find that unreasonable. The fact
that in this case its notion of a document happens to be a folder
shouldn't really be that important. IB having to rev every time some
new version control system comes along doesn't seem like the Right
Thing either, so something else should probably be developed. What,
exactly, is the question.
This becomes slightly more interesting in the case of the .rtfd
documents that TextEdit produces - although the name of the directory
is (say) foo.rtfd, it contains any number of filenames, none of which
you may know the name of - TextEdit and NSFileWrapper manage that
behind the scenes.
So the question I think becomes "Is there a way to treat these things
as 'atomic' without dumping their metadata someplace else?"
> Brian Fitzpatrick <fitz@apple.com> may know more about this (CC'd)?
In my other email address I work for the fruit company also... some
ideas have been kicked about, but here is my "Reader's Digest
Condensed Version" of some of the discussion:
Subversion's version numbering scheme solves the problems of getting
mismatched .nib elements inside the nib - you've either got version
619 of the project or version 618, but you won't get something
"inbetween" like you might with CVS.
But... you can't necessarily know anything about what's underneath
that top level directory at all.
The last I'd heard (the last email going around on this subject was 4
Feb) was that it'd be nifty to tag directories that should be 'atomic'
as 'opaque collections.' The client would then know that if it hit a
directory with this opaque collection property, it would basically do
a diff -r on that collection doing the diffs it can, removing files
that aren't in the collection anymore and adding the files that have
appeared, the metadata for these operations being stored in the .svn/
for the containing directory.
This gets the .svn/ data out of the document bundle, still gives you
effective versioning on the thing, as well as preserving information
about operations in a reasonable manner, leaving management of the
bundle contents to the owning application.
The added bonus seems to be that it also means you're not storing the
nib as a big wrapped blob in the repository.
Greg, Garrett, Bill, anyone else want to cover anything I've missed?
.chris
--
Chris Parker
Itinerant Graduate Student, Rensselaer Polytechnic Institute
Cocoa Frameworks Engineer, Apple Computer, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006