I have come across this issue multiple times before, Subclipse is issuing
two moves to subversion. Subversion does not handle the moves nicely. This
is an issue that Subversion has a bug out for, but the last time I checked
the bug tracker it was scheduled to be released in 1.4
-Trevor
On 3/20/06, David Corbin <dcorbin@machturtle.com> wrote:
>
> On Tuesday 21 March 2006 05:11 am, Toivanen Sampsa wrote:
> > Hello!
> >
> > I'm a bit confused by Subclipse's behavior when doing two consecutive
> > rename/move operations for a single file in Eclipse. For example, when
> > renaming first.txt to second.txt and immediately after that to third.txt
> > without a commit in between, Subclipse performs the following
> > operations:
> >
> > move C:/test/first.txt C:/test/second.txt
> > A C:/test/second.txt
> > D C:/test/first.txt
> > add -N C:\test\third.txt
> > A C:/test/third.txt
> > delete --force C:/test/second.txt
> > D C:/test/second.txt
> >
> > As a result of the latter explicit add and delete operations, the
> > resource history of third.txt is reset i.e. it shows nothing about
> > first.txt or second.txt. If, however, a commit was made after renaming
> > first.txt to second.txt, the resource history would then be ok all the
> > way up to third.txt.
> >
> > In my opinion, Subclipse should disallow the second rename operation in
> > eclipse, instructing the user to do a commit first.
> >
>
> In *my* oppinion, it should revert the first move, and then do the second
> rename as if the first never happened. (I'm sure that's a fair amount of
> work, of course, but that creates the best user experience).
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Tue Mar 21 15:08:57 2006