Tar wrappers in subversion‽‽‽‽‽‽‽
Update: Erik Scrafford of ZigZig wrote in with an explanation of what the script does. I misunderstood what he had done in the first place. In particular, he says:
All I’m doing is re-writing all the .svn directories and adding/deleting files as necessary so that people don’t have to run the svn commands by hand; it creates a tarball on the local system to backup the files, since this script isn’t terribly well tested yet. It should end up checking in exactly what you would expect; no interim formats in the repisotory like a tar wrapper solution.
That is significantly better than tar wrappers (the wrapping crap used in CVS). I need to review the script more closely to better understand exactly what is happening.
I had a brief look at the script. This is definitely not the mistake that was CVS wrappers.
My Perl is rusty, but the script is simple.
The script does have a data loss issue. If there are revisions in the repository and you execute the script, said revisions will be blown away upon next commit from your local machine.
The script needs to warn-and-abort if there are changes in the repository beyond the version you are working with locally. While it is likely the user won’t be able to merge in the traditional sense, the user should at least be informed that the operation they are about to perform is going to blow away changes that were committed to the repository.
Erik closes with:
But the script I put together solves a problem that lots of people are having right now; hopefully it ends up saving lots of people time and headaches trying to use subversion with bundles on macs.
That was the thinking that went into the original tar wrappers patch to CVS. The result has been 15 years of confusion, corrupted projects, and general pain. I was “Mr. Tar Wrappers” in the mid to late ’90s until Apple (Wilfredo Sanchez) took over and added it to Mac OS X. The scars run deep, hence the slightly knee jerk reaction.
Original Post
One of the Subversion core developers forwarded me this link.
In short, it adds an equivalent of CVS’s very broken “tar wrappers” to subversion in the form of a local hack that can be manually invoked to massage the data on the way in/out of subversion.
Wrong answer. Broken stuff. Weak sauce. Don’t do that.
Why? It effectively munges the data into non-diffable, non-original, format within the repository. There are many reasons why this is broken, most of which are outlined in this post I wrote in 2003.
(To be fair — it seems to be a reasonably implemented instance of a fatally flawed idea. And it isn’t automatic, so you won’t be automatically corrupting data in a misconfigured client side environment.)
Until Subversion properly supports opaque collections, whatever local hackery is done to work around or support this situation should make sure that whatever is checked into and out of the repository is in “native format”.
A script that makes a copy of– say– Foo.pages to Foo-svn.pages, and adds/manages Foo-svn.pages would be a much better solution because a “non script enabled” user could, at the least, open Foo-svn.pages with the only risk being that it becomes “disconnected” from the repository (which is really easy to fix).
Even that is a nasty hack that is nothing more than a flawed band-aid covering the real problem.
All of this comes back around to the need for Svn to support opaque collections. This is really two problems; moving the metadata (the .svn directory) out of the opaque directory (the Foo.pages) and automate inventory control within (i.e. don’t require svn add/delete for entries within the opaque collection).
Sadly, many people — some of the Subversion developers included, it seems — assume that the need for opaque collections is Mac specific.
It isn’t. Not by a long shot.
Just try and explain to a non-techie why you need to “add” and “remove” crap from a Svn repository when said non-techie can see the damned files right there in front of them via the Finder or IE. Now, do it with a straight face after they ask something like, “I see the list of files right there and I made ‘em that way! Why do I now have to go and tell something else that I made ‘em that way when it can clearly see exactly what I did in that window right there in front of me??!?!?!?!!”
Seriously. There are dozens of situations where “Just version control this big pile of crap automatically for me, thanks much.” is the exact right answer. Anything from collections of random notes/snippets through to the contents of a web site or the intermediate products in a content production environment all beg for this kind of solution.
In any case, tar wrappers or any other kind of client-side-pre/post-processing-before-commit/after-update is just a really, terribly, bad idea. I have spent more than the last decade dealing with fallout from CVS’s tar wrappers and I really don’t want to see the same stupidity perpetuated upon Subversion.
August 15th, 2006 at 3:24 pm
Unfortuntely, the “opaque collections” issue has been open since 2002 with no visible progress and no target milestone scheduled. I last added a comment to it back in December 2004 and no -one has commented since.
It seems it is very much perceived as a Mac-only thing, hence the lack of action. The only workarounds have been for well-behaved apps on the Mac side to be careful about Subversion metadata inside bundles in the working copy. Interface Builder is an example of a well-behaved application. TextEdit is an example of a poorly-behaved one. But clearly having support for opaque collections in Subversion would be better than trying to modify every single program that ever works with bundle-based documents.
August 15th, 2006 at 3:27 pm
Yeah, well, writing comments doesn’t solve the problem. Writing code, however, might. Someone needs to pony up the time to do it. In the meantime, people will make do with whatever hacks work for them.
August 17th, 2006 at 7:43 am
AFAIK, OpenOffice documents would also benefit from support for opaque collections in subversion. Not too Mac specific, is it?
August 18th, 2006 at 2:43 am
I’m the guy that wrote the script, thought I’d clarify a few things.
I’ve had a lot of people asking about dealing with bundles in ZigVersion, and so I scripted up what I had been doing to bundles manually. All I’m doing is re-writing all the .svn directories and adding/deleting files as necessary so that people don’t have to run the svn commands by hand; it creates a tarball on the local system to backup the files, since this script isn’t terribly well tested yet. It should end up checking in exactly what you would expect; no interim formats in the repisotory like a tar wrapper solution.
Of course, this was just a test script to help people out temporarily - the next step would be to integrate what it does (not the script itself) into ZigVersion, watching for the svn:opaque (or whatever) property, and doing the right stuff. Basically, acting exactly like what was suggested in the “opaque collections” issue, but deemed too hard or unimportant or whatever finally happened. I’m not to the point of adding it to ZigVersion yet (haven’t even decided this is the right thing to do), and I was going to bounce it around the subversion dev list first to see what kind of feedback I get on it; I guess someone caught wind of it sooner than I expected. Theoretically, this would work *exactly* like implementing it in the svn lib would work (assuming a hack that doesn’t require a new working copy format), and if it ends up getting into the svn lib in the future, should be a transparent upgrade. The solution isn’t
The right thing to do seems to be to throw out the way the working copy currently stores stuff (.svn), and do something else. I’ve toyed with the idea of supporting svk (in addition to svn) in some future version of ZigVersion in order to have the meta data stored outside of the direct filesystem (amongst other features); perhaps instead of doing what my test script does. But the script I put together solves a problem that lots of people are having right now; hopefully it ends up saving lots of people time and headaches trying to use subversion with bundles on macs.