Hello Subversion - Team,
We are working with Subversion on an evaluation basis for a few months now.
Overall it's a very good tool and we think about using it for our projects.
At the moment we are working with Subversion 1.1.3 and Tortoise 1.1.3 for
our development control. But I also reproduced this problem on the 1.1.4
versions, too.
As we also use Tortoise the problem occurred first there. I also found the
open issue 756 (http://subversion.tigris.org/issues/show_bug.cgi?id=756),
where this problem is stated to be of medium priority and has not been
touched since 2003.
The Problem:
Using tortoise (also with subversion this is not yet supported) it is not
possible to move (schedule a move) a file from Folder B to C after having it
moved (scheduled for) from A to B.
*** cut ***
Remember that a scheduled 'mv' is just a scheduled 'cp'
(add-with-history) followed by a scheduled 'rm'. And we *don't*
allow something to be copied twice. In other words:
svn cp A B
svn cp B C
is illegal, and needs to be prevented by libsvn_wc... which it's
apparently not doing anymore. The second 'cp' is clobbering the
entry's copyfrom-url field (which already existed from the first
copy.)
*** cut ***
I understand, that subversion does not allow moving an already moved file
again, as there may come up problems with the copyfrom-url, but I think
these problems could be solved.
Why clobbering the copyfrom-url? Simply leave it untouched, if the file has
not been committed yet.
The point, why I think this is not only a minor problem is, that I don't see
a reason, why the following behaviour is not ok.
Usecase1:
It could happen, that someone wanted to schedule a file to be added to
folder foo2, but by mistake he added it to foo1. This can easily happen by a
typo. And now he has to move the file to foo1, but has no simple way using
SVN. Instead he has to revert the add, move the file in the filesystem to
its correct location and again schedule it for adding.
It would be elegant, moving the file by simply using the svn mv command.
This move command should leave the repository in a state, as if the file
were scheduled for adding in the foo1 directly, and had never occured in
foo2.
Usecase2:
If someone moved a file (that is already under version control) to another
folder, and did that by misktake to the wrong target, he encounters the same
problem and would probably expect to repair that by moving the file again.
SVN should have all the information needed to perform this operation without
getting into conflicts or inconsistencies.
Background:
But this is not all. As your Software grows and gets more spreaded, tools
like TortoiseSVN will be used more and more by many users. These users
usually use features like drag&drop, where the described problem occures
much more often. Dragging to wrong folder occures probably more often than
typing a wrong name.
What I expected:
If I move a file twice (A->B->C), I expect the result to look as if I simply
moved it to the last folder.
If I move a file once and copy it again, I would expect to have the working
copy to look as if I had copied the original file twice and deleted it after
these two copy-operations.
So it's yust a point how the working-copy administration package andles sch
opperations.
All the information scheduling these behaviours are there somewhere and
could be used to have consistant behaviour over copies and moves, even if
the original file has been scheduled for deletion. At least revert must be
possible, so there must be the information somewhere.
I would be glad to hearing from you, working on this issue at some time. It
is an important issue, as developers are humans, and humans make errors. And
solving an error the way one usually does s probably the easiest. If I put
something to the wrong place by mistake, I don't want to be forced to move
it back to the original place and than moving it again to the correct place.
I would appreciate to correct my mistake by moving the file from the wrong
place to the correct place without any unnecessary detour.
At last I would say thanks to all delevlopers of SVN, I like that tool very
much.
Continue this way and make it a success.
Best regards,
Ansgar Lohoff
--
Ansgar Lohoff (Dipl.-Phys.) ansgar.lohoff@cryptovision.com
cv cryptovision GmbH
Munscheidstraße 14 Tel.:+49(209)167-2492
D-45886 Gelsenkirchen Fax.:+49(209)167-2461
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 7 18:54:43 2005