It sounds like what you're saying is, the priority of issue #756
should be raised, because people will encounter the bug much more
frequently now due to the spread of drag-n-drop tools like
TortoiseSVN. Is that a fair summary?
If so, would you mind annotating the issue to that effect, and maybe
putting in a pointer to this mail thread? (Yes, I could do those
things myself, but it's nice to parallelize as much as possible. Once
those changes are made to the issue, we'll look at moving it into an
upcoming release target -- perhaps not 1.3, which is already large,
but maybe 1.4 or 1.5.) I think your analysis makes a lot of sense.
Of course, if you have time to submit a patch, that would be the best
thing, and could get the issue fixed *much* sooner :-).
Best,
-Karl
"Lohoff, Ansgar" <ansgar.lohoff@cryptovision.com> writes:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 8 17:05:29 2005