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

Re: mv != (cp && rm)

From: Mattias Rönnblom <hofors_at_lysator.liu.se>
Date: 2001-11-28 00:19:09 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Mattias R�nnblom <hofors@lysator.liu.se> writes:
> > currently, svn mv is implemented by adding a new node and and
> > removing the old. This means that a file that is moved get
> > a new id, and there is now way of know wheter it is a actual
> > copy of the node in question, or if the user only wanted to
> > change the name of the node.
>
> Yes, there is a way -- the "history" is preserved in the repository.
> The newly created node knows that it is derived from the old node.
> See the `copy properties' in libsvn_fs.
>

It knows that is derived (copied) from the old node, but it doesn't
say if it is a copy as a part of the cp && rm procedure executed
to implement a mv or a "real" copy.

Compare this to a regular UNIX file system:

matro@isengard$~> echo foo > foo
matro@isengard$~> ln foo foobar

Now I've created a filesystem object with two names
If a do

matro@isengard$~> cp foo kex
matro@isengard$~> rm foo

I communicate "I want a copy of foo to be stored as the name kex.
Not the same object, but a copy."

Compared to

matro@isengard$~> mv foo kex

which says "I want to rename the file foo to kex. It should be
the same object, and modifications to kex should show up in
foobar.

> What you say about capturing the users' intention is true, but
> unfortunately that is not a problem of the mv operation itself, but
> rather of the commit. If the user chooses to commit only one side or
> the other of the move first, then you have one case. If she commits
> both sides in one commit, then you know it's a rename. This
> information is in the repository.
>

I think what I'm trying to say that there is just one side of a mv
command, and that changing the name of the node.

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.