mv != (cp && rm)

[Mattias Rönnblom <ho...@lysator.liu.se>]

Hi,

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.

Why is this a problem, you might ask? Currently, it probably isn't
really a problem (as far as I see).

But, we are losing information bye not make a difference between
move and copy && rm. In most cases, you probably don't care if
it a copy or the original (just as most users of commercial
software). But if you want to build some way of sharing node
(having two directories include the _same_ file (with the
same node id), for example) that information is useful.

And why do you need such a feature? Well, it is probably not *that*
important. But a use case migh be:

The project has three modules written in Java. The developers would
like to keep them self-contained, but they would also like to
share some util classes between the modules. A change in the util
classes in the module-a should automaticilly propagate to the
other modules. No symbolic links; the files in the wc should be
regular files.

This could be solved by having all the module directories contain
a reference to the same (node id-wise) util-directory. If
the user "svn mv"-ed that directory, he would probably like it to
be the same directory. Changes to the util directory should
show up in all modules, even though it has got a new name.

Someone could solve this by adding rename functionality to the
editor interface. This would slightly improve the design
(and use the currently un-used svn_fs_rename()) and making
sure that that someone could implement sharing nodes between
directories in the future.

Thanks to Ben for the help on #svn.

Kind regards,
        Mattias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: mv != (cp && rm)

[Mattias Rönnblom <ho...@lysator.liu.se>]

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

> Mattias R�nnblom <ho...@lysator.liu.se> writes:
> > 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.
> 
> In Unix, there is one side.
> 
> Subversion is not Unix.  In Subversion, it is possible to commit one
> side of the operation without committing the other.
> 
> What is your suggested behavior?
> 

I suggest the UNIX-like semantics.

//Mattias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: mv != (cp && rm)

[Karl Fogel <kf...@newton.ch.collab.net>]

Mattias Rönnblom <ho...@lysator.liu.se> writes:
> 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.

In Unix, there is one side.

Subversion is not Unix.  In Subversion, it is possible to commit one
side of the operation without committing the other.

What is your suggested behavior?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: mv != (cp && rm)

[Mattias Rönnblom <ho...@lysator.liu.se>]

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

> Mattias R�nnblom <ho...@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

Re: mv != (cp && rm)

[Tom Rini <tr...@kernel.crashing.org>]

On Tue, Nov 27, 2001 at 05:01:22PM -0600, Karl Fogel wrote:
> Mattias R?nnblom <ho...@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.

Hello.  From a user who's using a version control system that has a 'mv'
command, in subversion if we move trunk/dir1/a to trunk/dir2/a, on the
repository side we get a copy and rm of the old, but the history is
preserved, yes?  As along as the user can see what happened to
trunk/dir2/a whenit was trunk/dir1/a,  I don't think it matters if we
'move' the file or 'copy and delete original'.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: mv != (cp && rm)

[Karl Fogel <kf...@newton.ch.collab.net>]

Mattias Rönnblom <ho...@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.

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.

IOW, because the user can choose to commit only part of the mv at a
time, this issue is a little more complex than it might at first
appear. :-)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org