text: Vincent Starre wrote:
  > can I bring
  > up once again that repository-side linking should be available? Is there
  > an issue open for this?
  I'd like to support this request too. I imagine it is difficult to
  implement, but it would solve a lot of problems, and prevent some of the
  abuses of svn:externals.
  Like most filesystems, subversion implements tree-structured
  directories. Tree-structured namespaces are fine for the most part, but
  as most any OS text will tell you (e.g. Silberschatz, "Operating Systems
  Concepts", 6th Edition, page 441), they have their problems. In the OS
  context, the usual example is two users who want to share a common
  project. Subversion is ideal for this, because the two users can refer
  to the same subversion name, and they will get the same thing.
  [Of course, M$ filesystems don't provide links, but I'm not sure that is
  a good example to follow.]
  In our particular case, one example that doesn't work well arises from a
  bootstrapping problem. We have 1) a build system, and 2) a standard
  library (). The standard library is compiled
  with the build system, but the build system requires a fragment of the
  standard library. Our practice with cvs was to define server-side
  links, which was a pain, but reasonably transparent once done. With
  subversion, we use svn:externals to point to the entire standard
  library, then use client-side links to extract the fragment. While this
  works, support is not transparent--some commands traverse svn:externals,
  some don't. In particular, "svn copy" ignores svn:externals, so we
  often wind up with broken links.
  Of course, we could "svn copy" each of the individual files in the
  fragment, but this creates a branch. The two versions of the files tend
  to drift apart, leading to a merging quagmire.
  The usual problem with links in general is what to do when the target's
  name changes. Unix filesystems also provide hard links (as the saying
  goes, "Any naming problem can be solved by introducing another level of
  indirection":). A file can have many names, but it has exactly one
  inode. Hard links refer to inodes, not file names, so they are
  relatively immune to filename changes. Locking isn't an issue either,
  since the lock is based on the inode, not the filename.
  It would be awesome if similar principles would work in subversion.
  % svn ln a b # a and b refer to the same thing
  % echo Moo > b # Change b
  % svn commit b # Save b
  % svn up a # a now contains the line "Moo"
  % cat a
  Moo
  % svn mv b c # Now a and c are the same
  % echo Boo > c
  % svn commit c
  % svn up a
  % cat a
  Boo
  Jason
  --
  Jason Hickey
  Caltech Computer Science Tel: 626-395-6568 FAX: 626-792-4257
  ---------------------------------------------------------------------.