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

Re: Subversion != your filesystem (was mv != (cp && rm))

From: Mattias R÷nnblom <hofors_at_lysator.liu.se>
Date: 2001-11-28 22:38:22 CET

"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,

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

This is an archived mail posted to the Subversion Dev mailing list.