This message consists of several emails that went back and forth at the
beginning of the year, and I've finally managed to put aside some time
to act on them. This is a prelude to part 2 of this series, which is a
Request for Comment WRT implementation of 'document bundles' or
'Collections' in Subversion.
-Fitz
> From: Chris Parker <ctp@apple.com>
> Date: Mon Jan 28, 2002 05:05:01 PM US/Central
> Subject: svn proposal
>
> [snip]
>
> Apple's development tools for Cocoa include a thing called Interface
> Builder (IB). IB's fundamental document structure is what appears to
> the Finder as a .nib file. In reality, this is a directory with a
> bunch of different files in it. The format and contents of this
> directory have changed and may change in the future.
>
> The problem of course, comes when you try to deal with these things
> in version control you wind up with CVS/ directories in the nib,
> which isn't the right thing. A much earlier thread
> (http://subversion.tigris.org/servlets/ReadMsg?msgId=22734&listName=dev
> - I'll might refer to this as "TET" for "That Earlier Thread" later
> on in this email) describes this briefly, but doesn't really do much
> for outlining the issues completely or possible solutions.
>
> I think that the key concept here is the fact that for the average use
> of a nib (or any other document bundle situation), that directory
> itself is effectively a document. The programmer working with them
> thinks of the nib itself as a document - a single, atomic thing. The
> tools that deal with the nib (IB) "think" of it atomically as well.
>
> Proposal:
>
> An attribute placed on directories to indicate atomicity of
> operation - i.e. any directory with this attribute would not contain
> an .svn directory, and the operations occurring on that directory
> would occur on its contents as appropriate. This attribute should be
> off for everything by default, but svn users should be able to set it
> to kick in automatically for certain conditions (e.g. any directory
> with the .nib extension should be treated as an atomic thing).
>
> I. Creating a nib and adding it to version control
>
> Situation:
>
> Let's assume for a second we've got a project that's already in
> version control and we're adding a nib to it.
>
> The developer opens up IB, creates a new nib and fiddles with it a
> bit. They quit IB, saving their nib as foo.nib and now they want to
> add it to version control. This has created a directory in the
> working copy called "foo.nib" with (at present) three files in it:
> classes.nib, info.nib, and objects.nib (note that at present,
> classes.nib and info.nib are text files, but objects.nib is a binary
> file - all of that could change, too).
>
> Discussion:
>
> Moving the metadata to Someplace Else so IB doesn't trash the data is
> a one-aspirin fix I believe, since it's not unreasonable for IB to
> expect that its documents are its to control.
>
> How The Proposal Addresses This:
>
> By being able to set the "atomicity" for a given set of directory
> types by default (i.e. any directory with .nib should be treated as
> a unit), the add operation is at this point a one-shot thing with no
> "wrapping" necessary as it was in CVS. The developer's model of the
> document, IB's model of the document, and svn's model of the
> document all match.
>
> II. Changing an existing nib that's already in version control
>
> Situation:
>
> The developer checks out a working copy with foo.nib in it, fiddles
> with it and saves the changes. Developer now wishes to commit.
>
> Discussion:
>
> In most cases, this will cause updates to the three files in the nib
> bundle. The diff on the document is the union of the three diffs of
> the files contained in it.
>
> How The Proposal Addresses This:
>
> Here again, the proposal doesn't do much other than keep the svn
> stuff out of the document bundle itself - the commit would appear to
> be atomic in svn anyway it's really the presence of the .svn
> directory that this continues to avoid.
>
> III. Changing an existing nib that's already in version control and
> that requires the addition/deletion of a new file to/from the
> nib.
>
> Situation:
>
> Developer checks out the above project with foo.nib in it. foo.nib
> winds up in the working copy, and the developer opens it up and
> starts working on it with IB. Let's say that she adds something to
> the nib that requires the addition of a file to the nib bundle - so
> now, the thing has classes.nib, info.nib, objects.nib and
> connections.nib inside it. Changes have probably been made to the
> three pre-existing files, but now there's that additional
> connections.nib file.
>
> This situation also comes up with the act of adding, say, a .jpg
> file to the nib.
>
> Discussion:
>
> In order to deal with this correctly, the commit operation should
> pick up the fact that that new file is present inside the nib
> bundle. Having to do a separate add operation on that internal file
> (from the developer's perspective) breaks the model for document
> bundles.
>
> How The Proposal Addresses This:
>
> Here's where things really get "interesting" I suppose. The diff
> here winds up being the changes to the three files, and the add
> of the new file. The commit is against the nib bundle, and the
> atomicity property allows version control to deal with the issue
> without wrapping. Similarly for removal.
>
> Thoughts? Opinions? Questions?
>
> .chris
--------------------8-<-------cut-here---------8-<-----------------------
> From: Bill Bumgarner <bbum@codefab.com>
> Date: Tue Jan 29, 2002 12:50:53 PM US/Central
> Subject: Re: svn & opaque collections
>
> [I believe Chris's post addressed a lot of the same concepts as here,
> but I'm both going to reiterate to add support and to, hopefully,
> normalize vocabulary.]
>
> First, some background-- I have been thinking about this for quite a
> long time (as I really, really, really want to see CVS go away):
>
> http://lists.w3.org/Archives/Public/ietf-dav-
> versioning/2000JulSep/0186.html
>
> Assumption: We are using the DAV vocabulary for referring to
> directories and files as collections and resources.
>
> To restate the problem: We need to be able to version control a
> collection-- be it a collection of resources or a hierarchy of
> collections with resources throughout, does not matter-- as if it were
> a single resource. That is, the collection is opaque from the
> perspective of; an 'opaque collection'.
>
> To these ends, an ideal solution would not modify or add to the
> contents of the collection in any way. In particular, it would not
> assume that it can store administrative information within the
> collection because there is no guarantee that said information would be
> preserved. Worse, there is a very good chance that it would be
> preserved, but moved into a new collection as a part of the normal
> process of working with that particular opaque collection [opaque
> datatype].
>
> Though I stated in the previous message that NIB files do not need to
> be wrapped, there is a distinct advantage to treating them as an opaque
> collection in that it will automatically address the issue that
> occasionally arises when there IS something within the NIB that cannot
> be easily quantified (like one of those goofy named images that results
> from dragging an image into the NIB file).
>
> The same holds true for EOModel files and WebObjects Components. But it
> would be to great detriment if treating them as truly opaque
> collections lead to the inability to easily glean accountability for
> changes within the files. I.e. we really want to preserve the ability
> to have functionality like 'cvs annotate' for the individuals files
> within an EOModel.
>
> So, assuming the case has been sufficiently made for the ability to
> version control an opaque collection-- a directory full of contents
> that cannot be sensibly or predictably inventoried and whose contents
> we have zero control over-- then, a solution that does the following
> would be highly desirable:
>
> - treats everything below the collection as completely outside of
> the system's ability to inventory and/or individually control
>
> - preserves the ability to generate an inventory of specific
> changes between any two revisions of the opaque collection [i.e. cvs
> annotate with opaque collection awareness; nothing more than a 'diff
> -r' with some prettified output].
>
> - does not place any kind of administrative information inside the
> opaque collection; the opaque collection is treated truly as a resouce
>
> - stores the opaque collection on the server such that a recursive
> GET [assuming WebDAV/HTTP backing store] restores a tree that acts like
> a working work area
>
> - can be easily enabled/disabled on a per collection basis, as needed.
>
> A lot of this implementation can be achieved by simply augmenting the
> 'identify if resource has changed' algorithms to recursively descend
> opaque collections. For features such as 'diff' or 'annotate' it is
> mostly a matter of sacrificing some CPU cycles to make up for the more
> complex recursive collections versus the normal case of a 'scalar'
> resource.
>
> Or so I believe...?
--------------------8-<-------cut-here---------8-<-----------------------
> From: Wilfredo Sánchez <wsanchez@mit.edu>
> Date: Wed Jan 30, 2002 02:16:28 PM US/Central
> Subject: Re: svn & nibs
>
> As Brian pointed out, the version in SVN largely obviates the problem
> of individual resources in a NIB file getting versioned independently.
>
> It seems to me that the only real pain is the business of
> automatically adding/removing resources in the NIB file so the user
> doesn't have to think of those resources as being independent, which is
> inconsistent with the NIB as a file notion.
>
> I do think this is doable in the client (the tool, not the SVN
> library), be that a GUI AppKit/Carbon type client or the IDE. And I
> think it's OK if the command line version didn't also do this. In the
> command line view, the NIB file is a directory. In order to reliably
> recognize bundles as such, you need to at least live above the
> CoreFoundation level anyway. The SVN client library shouldn't poke up
> that high.
>
> The business of turning an RTF into an RTFd is not dissimilar from
> turning a GIF to a PNG. That's probably considered a new file. I
> don't see this as a related problem.
>
> Given that, the only real outstanding issue is the business of
> keeping administrative data in the collection-turned-resource.
> Ideally, this would always be guaranteed, regardless of some "keep
> turds at the top of the tree" option.
>
> -Fred
--------------------8-<-------cut-here---------8-<-----------------------
> From: Bill Bumgarner <bbum@codefab.com>
> Date: Wed Jan 30, 2002 02:31:51 PM US/Central
> Subject: Re: svn & nibs
>
> The problem is larger than just NIB files and more complex.
>
> In an RTFD, each save can cause the names of the various wrapped
> images/resources to change. Via the NSFileWrapper API, the hash
> between the symbolic name of a resource and the filesystem name (and,
> frankly, structure of the contents of the file wrapper) is largely
> isolated to the point that a developer could easily expect that
> everything within their wrapper is fully under their control. I.e.
> they have zero expectation that filenames or directory structure needs
> to remain at all consistent over time.
>
> Back to opaque collections.... assume that a NIB, an RTFD, or-- by
> default-- any other File Wrapper that points to a directory is an
> 'opaque collection'.
>
> I agree with Fred that automatically adding/removing resources within
> an opaque collection is outside of the bounds of implementation of the
> non-native portions of the svn client. However, I would also pose
> that it is likely outside of the bounds of the native client, as well,
> unless that client explicitly has built in support for a particular
> style of opaque collection.
>
> For the svn client to work seamlessly and flawlessly across any random
> tree of resources one might throw at it, it needs to be able to treat
> any random directory full of stuff as a truly opaque collection. That
> is, it needs to be able to revision control a directory and its
> contents as a single atomic operation [supported now in svn by the
> collection version numbers] while also assuming it has zero ability to
> draw conclusions based on the inventory of the contents within the
> opaque collection.
>
> To put it in simple terms: The client cannot assume that because the
> contents of an RTFD is currently...
>
> 10__#$!@%!#__Table.pdf 2__#$!@%!#__Table.pdf 6__#$!@%!#__Table.pdf
> TXT.
> rtf
> 11__#$!@%!#__Table.pdf 3__#$!@%!#__Table.pdf 7__#$!@%!#__Table.pdf
> Table.pdf
> 12__#$!@%!#__Table.pdf 4__#$!@%!#__Table.pdf 8__#$!@%!#__Table.pdf
> 1__#$!@%!#__Table.pdf 5__#$!@%!#__Table.pdf 9__#$!@%!#__Table.pdf
>
> ... and that document is saved preceding a commit request, that the
> inventory of files will even be remotely the same. Similarly, the
> client should not assume that changes to '3__#$!@%!#__Table.pdf'
> between any two revisions actually represent real content changes-- it
> could just easily mean that the RTFD file wrapper decided to rename a
> bunch of the existing files because of an addition, deletion or simply
> out of spite!
>
> The bottom line is that as soon as we make any assumptions about
> predictability of contents within opaque collections between svn
> operations, we create a system that will either eventually break on
> some random wrapper type we didn't imagine during implementation or a
> system that generates massive amounts of reporting noise for these
> types.
>
> b.bum
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 23 07:39:49 2002