Wilfredo S=?iso-8859-1?q?=E1?=nchez <email@example.com> writes:
> Note that having SVN/ turds in each directory in the working copy
> assumes that people operate on files, and not whole directories.
> The reason I bring this up is that CVS has this property and this
> is the reason why the dreaded t/f wrappers were invented.
> NeXT had (and now Apple has) many tools which treat directories
> as opaque objects (bundles), which to the user look and feel like
> files, and not directories. Editors tend to write out a new
> directory on save, and (being unaware of them) will zap the CVS/
> turds in the bundle.
> So stowing away the metadata in on SVN/ turd at the top of the
> working tree would be cool, from the point of view of not having
> to worry about that problem any more.
Having an SVN/ dir in each subdirectory means you can treat that
subdirectory as an independent working copy -- move it somewhere else,
and it still works. This is really handy; CVS users actually do move
stuff around like this.
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.
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
Received on Sat Oct 21 14:36:07 2006