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

collected vs distributed working copy metadata

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-08-09 16:17:31 CEST

Since there's recently been some discussion about possible
arrangements of meta-data in the working copy, I'd like to solicit

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

Received on Sat Oct 21 14:36:06 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.