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
Received on Tue Mar 28 10:06:39 2006