"Bill Tutt" <rassilon@lyra.org> writes:
> So, if you want links, I'd highly recommend doing the symbolic link
> approach first. They fit much more nicely into SVN's data model, don't
> have issues when people create a branch (since they can be
> path-relative), and are certainly much easier to implement.
I think you misunderstand, or perhaps VSS's implementation was
poorly thought out. Let's look at it in the Unix filesystem first.
You have three files, foo, bar, and baz. foo is a regular file,
bar is a link, and baz is a symbolic link. You 'cp foo bar baz
quux' where quux is a directory. Then you echo a bit of text to
the end of each file in quux. With foo and bar (the regular file
and hard link, respectively), the originals have not been modified.
With baz, the original has been modified (assuming it pointed at
an absolute path, of course).
That's exactly how i see svn's links working (at least hard links,
as i've said, i'm not terribly interested in soft links). Now
let's see how this works in svn:
You have the following nodes:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/foo.c # file
svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
Now you have a link (called doctools) in foo. After a few months
of work, you 'svn cp trunk/foo/ branches/foo/foo-2.0'. Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools/ # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
/branches/foo/foo-2.0/doctools/ # *copy* of /trunk/tools/doctools/
/branches/foo/foo-2.0/foo.c # *copy* of /trunk/foo/foo.c
Committing in doctools on the branch affects no other copies. Note
that no one dereferenced the link, just as in the Unix filesystem.
That's just the nature of hard links; they exist in directory nodes,
not file nodes.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 3 02:15:02 2002