Since there's recently been some discussion about possible
arrangements of meta-data in the working copy, I'd like to solicit
opinions.
The current design is that each subdirectory of the working copy has
its own "SVN/" (or ".SVN/") subdirectory.
Some advantages of this scheme:
1. Subdirectories are detachable -- any working copy subdir is
itself a fully independent working copy, so you could move it
somewhere else and it would still work.
2. Administrative information and base versions are close by in
case one needs to examine them by hand (which, if CVS is any
guide, is probably inevitable).
3. It's nice to be able to tell, when you cd directly into some
random subdir of a working copy, that you are in a working
copy. The presence of the SVN/ subdir is a very visible flag --
for example, when your working copy includes subdirectories that
are *not* under version control, you can easily distinguish them
from subdirs which are, just by doing `ls'.
Some disadvantages:
1. `find', `grep', and wildcard globbing get interfered with by the
SVN/ subdirs, so you have to be extra careful with such things.
CVS users know from experience that this can be annoying. :-)
2. It may be a bit harder to implement than just keeping all the
metadata in one place (presumably in the top of the tree, or in
a sibling of the top of the tree). I'm not sure about this,
though, not having thought as much about implementing
metadata-in-one-place as I have about per-subdir metada.
I'd like to know what people think about this issue, especially if you
can add some advantages/disadvantages not listed here. The working
copy library is solidifying, but it's not committed to one way or the
other yet; before we write that code, we should make sure we're not
missing some big point.
So: thoughts?
(Note that this is *not* a question about whether it should be "SVN/"
or ".SVN/" -- that's just an option, svn should handle both. If one
chooses .SVN/, that alleviates globbing issues somewhat.)
Thanks,
-Karl
Received on Sat Oct 21 14:36:06 2006