rename problem

[Andrew Gabriel <An...@clearswift.com>]

I think we may have found a problem in subversion, which leads to loss
of changes to a file when it is renamed under certain circumstances.
It was first reported to me by staff using the Eclipse client on
Windows XP, but I have reproduced it using the command line on Unix
too. Subversion is 1.3.0 (server Solaris x86, client Linux x86),
using svn:// access mode. The scenario to reproduce goes like this...

Assume person A and person B have a checked out workspace, and for
simplicity, we'll assume they checked out the same revision 1000
(although that's not a prerequisite). Person A edits a file and
commits it back creating revision 1001. Person B still has the older
revision in their workspace and renames this file. When person B
attempts to commit, Subversion correctly points out their workspace
is out of date. So person B updates their workspace which appears to
work fine, but actually hasn't changed the file contents. Person B
now commits their change creating revision 1002. The copy part
of the rename operation is shown as being copied from revision 1000,
thus losing the revision 1001 change.

Is this a known issue?

-- 
Andrew Gabriel


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

Re: rename problem

[Garrett Rooney <ro...@electricjellyfish.net>]

On 3/28/06, Ryan Schmidt <su...@ryandesign.com> wrote:

> True renames are currently slated for Subversion 1.4.
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=898

Just to avoid getting people's hopes up, it's INCREDIBLY unlikely that
any user visible evidence of renames support will show up in
Subversion 1.4.  There is currently work going on at implementing the
very lowest levels of rename support within the filesystem (see the
fs-atomic-renames branch), but even when that's done it won't be
visible to the user because there won't be any support in the client
for actually executing a rename.  The higher level parts of the rename
functionality are going to require a lot of work, and we're a long way
away from predicting what version of Subversion it will ship with.

-garrett

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

Re: rename problem

[Ryan Schmidt <su...@ryandesign.com>]

On Mar 27, 2006, at 23:42, Andrew Gabriel wrote:

> Assume person A and person B have a checked out workspace, and for
> simplicity, we'll assume they checked out the same revision 1000
> (although that's not a prerequisite). Person A edits a file and
> commits it back creating revision 1001. Person B still has the older
> revision in their workspace and renames this file. When person B
> attempts to commit, Subversion correctly points out their workspace
> is out of date. So person B updates their workspace which appears to
> work fine, but actually hasn't changed the file contents. Person B
> now commits their change creating revision 1002. The copy part
> of the rename operation is shown as being copied from revision 1000,
> thus losing the revision 1001 change.
>
> Is this a known issue?

I believe this falls under the missing Subversion "true renames"  
feature. So once that's implemented, this problem goes away.


It's better to provide a transcript of commands you executed than an  
English description. I tried to create a transcript from your  
description:

$ svnadmin create repo
$ echo hello > foo
$ svn import foo file://`pwd`/repo/foo -m "Add foo"
Adding         foo

Committed revision 1.

# Assume person A and person B have a checked out workspace,
# and for simplicity, we'll assume they checked out the same revision 1.
$ svn co file://`pwd`/repo personA
A    personA/foo
Checked out revision 1.
$ svn co file://`pwd`/repo personB
A    personB/foo
Checked out revision 1.

# Person A edits a file and commits it back creating revision 2
$ cd personA
$ echo world > foo
$ svn ci -m "person A changes foo"
Sending        foo
Transmitting file data .
Committed revision 2.

# Person B still has the older revision in their workspace and
# renames this file.
$ cd ../personB
$ svn mv foo bar
A         bar
D         foo

# When person B attempts to commit, Subversion correctly points
# out their workspace is out of date.
$ svn ci -m "person B moves foo to bar"
Adding         bar
Deleting       foo
svn: Commit failed (details follow):
svn: Out of date: 'foo' in transaction '2-1'

# So person B updates their workspace.
$ svn up
U    foo
Updated to revision 2.
$ svn st
D      foo
A  +   bar

# Person B now commits their change creating revision 3.
$ svn ci -m "person B moves foo to bar"
Adding         bar
Deleting       foo

Committed revision 3.

# The version person A committed in revision 2 remains in
# the working copy as an unversioned file.
$ ls
bar     foo
$ svn st
?      foo
$ cat foo
world
$ cat bar
hello
$

As you can see, after person B commits the rename, they are left with  
the file of the original name still in their working copy,  
unversioned, with the contents person A added. At this point, person  
B can ponder why this might be so, might consult the Subversion log,  
realize that this change was made by person A, and then attempt to  
integrate that change with the newly renamed file. Not optimal, but  
person B does have a chance to discover and correct the situation.  
And of course the repository keeps all changes forever so no work can  
ever be truly lost.


True renames are currently slated for Subversion 1.4.

http://subversion.tigris.org/issues/show_bug.cgi?id=898



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