[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bundles Re: SVN, .SVN, and other meta-data directorys

From: Wilfredo Sánchez <wsanchez_at_apple.com>
Date: 2000-08-23 06:09:31 CEST

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

        -Fred

Wilfredo Sánchez, wsanchez@apple.com
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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.