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 (http://omake.metaprl.org). 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 http://www.cs.caltech.edu/~jyh
Caltech Computer Science Tel: 626-395-6568 FAX: 626-792-4257
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Sep 18 01:41:53 2005