> I once ran into the zapping problem you mention, with a WebObjects
> tool (I can't remember which one, but it sure got me good :-) ). With
> all due respect, I think that's just ill-behaved. We shouldn't design
> to compensate for a tool that randomly destroys data it doesn't
> recognize; instead, the tool should be fixed.
Sure, I've made that argument, in fact; but it does go both ways. The
editor owns that data, and CVS is dropping turds into someone else's data.
You're just assuming that because it's a directory, that this can be gotten
away with, and usually, you are correct. But should these tools really
copy whatever junk happens to magically appear into their bundles? Not
really; you get .nfs9834876 turds from some NFS clients, for example,
which you certainly don't want to keep around, etc. So it's not so simple.
> Even storing all the data in one SVN/ dir at the top of the tree
> wouldn't solve this problem, anyway -- what if you used one of those
> editors on the root of the working tree? The SVN/ dir would still get
> zapped. So the problem might not occur as often, but it would still
> happen sometimes.
That's not at all likely. Presumably a project is a directory with
files in it which the user manages. Bundles are opaque to the user;
they look like files, but they happen to be implemented as directories.
Ideally, your revision control system would also recognize them as
single objects, which is why the t/f thing got invented.
Perhaps I'm looking at this sideways. Yup, I am. The better solution
is for something less simpleminded than t/f wrappers, but which also can
treat these things as single objects, and the SVN/ turd problem becomes
moot in that context. This goes back to how we want to handle
(encode & store, diff, etc.) other-than-ASCII-file data, a more
interesting and useful problem to solve.
Wilfredo Sánchez, firstname.lastname@example.org
Open Source Engineering Lead
Apple Computer, Inc., Core Operating System Group
1 Infinite Loop, Cupertino, CA 94086, 408.974-5174
Received on Sat Oct 21 14:36:07 2006