"Florin Iucha" <florin@iucha.net> writes:
> On Wed, Nov 28, 2001 at 03:55:05AM +0100, Branko �ibej wrote:
> > Once we implement "svn ln" (which means a third kind of node, a
> > "reference", will appear in the filesystem), we'll have to be careful to
> > preserve the semantics of reference nodes within a copy. But that's
> > trivial -- reference nodes will behave exactly like C pointers: a copy
> > creates a new node, but its value (the node it refers to) remains the same.
>
> What will happen if I link A to B and then
> 1. cp B C && rm B
> 2. mv B C
>
> You can argue that in both cases A will link to C but, then what happens
> when
If you argue that A will link to C in both cases, you are suggesting
symbolic links. If you say that it's only in the second case
A would refer to the same node-id as C, you have a something
close to what was behind my original use case in the beginning
of this thread, which is more like hard links in a UNIX filesystem.
> cp B C && change C && cp B D && change D && rm B && commit
> where does A point to now?
>
In the "hard links" model, A points to the node-id originally pointed
to by B. When the name B is removed, that node is only known by
one name; A. As far as I see, the most intuitive is that all
names of a specific node are equal. "svn link" or "svn ln" is
probably a bad name for this operation, as it is as confusing
as the overloaded "ln" command in UNIX. D is just a copy;
a new node-id with only one name: D.
Kind regards,
Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006