[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: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-08-21 23:03:27 CEST

Wilfredo S=?iso-8859-1?q?=E1?=nchez <wsanchez@apple.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
happen sometimes.
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.