Initial required flame inducing comment: Ick.
> From: B. W. Fitzpatrick [mailto:fitz@red-bean.com]
>
> Handling collections (aka document bundles) in Subversion requires a
> few changes to the way that working copies handle administrative file
> directories (i.e. ".svn" directories). These changes affect working
> copies only, and files inside of these collections will not be handled
> differently than any other file in the Subversion filesystem.
>
>
> Proposal:
>
> - Have a property that, when set on a directory, signifies "This child
> directory is a collection and the adm_files_dir of this directory
> should be kept in our adm_files dir".
>
> - For example:
> $ cd mydir
> $ ls
> foo bar Main.nib qux
> $ svn propset svn:Main.nib collection .
> (Note that I'm setting the property on the parent directory. I
> chose to do this because, when checking out a directory, we don't
> have the properties of the directory itself yet. Any suggestions
> WRT The Right Way of doing this would be welcome.)
>
This is actually a non-interesting wash case. I don't really care very
much where the silly property goes. As you say, it'd be nice if it got
stuck on Main.nib in the repository.
> - Main.nib's .svn dir would become
> mydir/.svn/collections/Main.nib/
>
> - Have a property that, when set on a directory, signifies that the
> collection is to be treated as opaque. That is, the contents of the
> directory should be added and removed from version control as they
> are added and removed from the filesystem.
>
> - For example:
> $ svn propset svn:Main.nib opaque-collection .
>
Ok so far. Still, doesn't matter where we set the property.
>
> Changes we'll need to make:
>
> - With the exception of a few references to SVN_WC_ADM_DIR_NAME in
> libsvn_client and clients/cmdline, these changes will take place
> almost exclusively in libsvn_wc. (Bullet points represent iterations
> that can be tested and checked in atomically):
>
> - Rework code that refers directly to SVN_WC_ADM_DIR_NAME to use a
> function (perhaps named svn_wc_adm_dir) to obtain the path to the
> administrative directory in question.
>
> - When a working copy is checked out, the admin directory needs to
> be put in the right place (i.e. in the parent's adm_files_dir) for
> collections.
>
> When the user does any other action (update, checkin, etc)
> libsvn_wc needs to go to the right place to get administrative
> data.
>
> - When the user does a checkin (perhaps also when we update?),
> libsvn_wc need to add/remove files from opaque collections as
> appropriate.
>
Subversion operational aspects:
Checkin: Yeah. Add/remove as appropriate.
Update: Ditto.
Copy: Different edge case to handle on the libsvn_wc side and repository
side semantics are obvious here.
Delete: Pretty apparent what happens here.
Move: Implied from Copy/Delete behavior.
Merge: Merges happen on the members of the opaque collection. Unless
libsvn_wc has an uncanny clarity into the format of these files then
either merge won't work from Subversion, or merge needs additional input
information from the driving app that knows about them to know where to
store conflict files, etc...
Add: Not applicable.
Diff: How does libsvn_wc get at the WC version of the internal contents
of the opaque collection?
Additional issues you didn't mention/specify, some of which I've
mentioned above:
How does libsvn_wc figure out how to iterate the contents of this opaque
collection? How does libsvn_wc figure out how to determine that anything
has changed? i.e. What minimum set of information is required in order
for libsvn_wc to be able to even attempt to work some helpful magic? How
does libsvn_wc do this in a platform independent manner? I highly doubt
that the opaque collection is a .tar file. :) How does libsvn_wc
correctly restore the opaque collection as it was submitted? How does
libsvn_wc determine the entire set of possible opaque collection types?
How does libsvn_wc determine the exact type of opaque collection so that
it knows which "opaque collection provider" to bug? Does libsvn_wc allow
opaque collections that contain sub-collections? i.e. Would this code be
usable for OLE structured storage documents? (filesystem in a file, more
or less) What sort of restriction would libsvn_wc place on the internal
formatting of the opaque collection? i.e. Are you guaranteed that the
opaque collection is going to use a normal file system like path syntax?
(/ being the separator)
Those are but the tip of the iceberg of issues that haven't been
mentioned yet. I'm sure other folks can think up lots more. :)
> - We need to write some test cases for this to make sure we don't
> screw up anything else. :)
>
>
> Comments appreciated. Flames will be backed up to tape, restored,
> printed out, and used for kindling.
>
Personal opinion on people who create opaque collections and want folks
to deal with it:
People who create files like this and want to version their contents
sanely (assuming versioning the contents means more than just storing a
binary diff) deserve what they get. Set a mime-type for the sucker, have
a pluggable diff mechanism, and use it. Either create a real virtual
file-system layer that doesn't trounce on 3rd party app data, or cope
with the consequences of doing things this way. It's not as if we don't
have other (and more interesting fish to fry).
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 23 09:51:00 2002