Re: Collections in Subversion. Part 2 of 2: Request for Comment

> 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).
>

Seems to me that the problems introduced by "files like this" are exactly the same ones introduced by any binary file format (like say a gif).

To illustrate: several years ago my company wrote and sold a tool for doing SCM in the NeXT (now Apple) environment that is being discussed in this thread. Dealing with file packages correctly was an important feature in that market. Our solution to .nib and .rtfd packages was to tar and gzip them transparently on the client, check in the tgz file on the server with a special property identifying it as a file package. Essentially, we made sure that they were just another opaque binary file to the SCM tool.

As is mentioned earlier in this thread, none of that is a big deal for SVN to handle (doesn't even need the tar-gzip step) and it wasn't a big deal for us to handle. The BIG deal was that doing diff/merge of these files was absolutely impossible and I think this is what has emerged in this thread. Even if you had the tool that would do the diffing for you, you have no idea after using the tool of whether or not the merged file had the same semantic meaning anymore and no way to reliably resolve the conflicts.

My point is that I have the exactly same problem with SVN today and committing graphics files.

We solved it in the earlier product by introducing "exclusive" locking of files and telling people that for binary file types (or any file type for which diff3 was likely to produce poorly resolved conflicts from a semantic standpoint) they needed to enforce a development protocol of 1) obtain the lock 2) make the changes and 3) do the commit. Things that were exclusively locked in this sense were set by the client at update time to be read-only in the working copy file system to encourage the user not to make unconsidered changes, and the server carried a property showing which user held the lock, so that users could negotiate file contention amongst themselves. Users quickly adapted to this technique because the pain of one lost revision was intense enough to force them to. :^)

Anyway, the solution we adopted was to provide information in the tool to enable a social system to work rather than forcing people to write "pluggable diff mechanisms" of varying reliability for each conceivable binary mime-type. Something similar could work here with the addition of another property or two and some relatively minor tweaking in the client lib. (Not that I've actually tried to change the code :^) ). Just a thought..

rvs

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 23 15:13:36 2002