news <news@sea.gmane.org> wrote on 04/19/2005 10:55:37 AM:
> Using 0.9.30 I'm usually pretty happy with Subclipse, but today noticed
> something odd that I could not explan until I thought further about it.
> Suppose you work on a class, rename it (e.g. via Refactor->Rename),
modify
> the newly renamed class by adding new code and then rename it back to
its
> original name because you realized the new name wasn't the best idea. It
> seems that subclipse does not correctly track this renaming and forgets
> about this file's state, so that a commit omits it. I accidentally found
> this when my commit done in eclipse didn't show up in another working
> copy; inspecting the eclipse working copy with TortoiseSVN it says the
> file has been "superseded" (I think - sorry if it's not the right term)
> and still needs to be commited.
> Am I pushing Subversion's renaming mechanism in general (which still
seems
> to be based on delete/add in 1.1) or is this something that Subclipse
(or
> svn) should get right?
First to clarify something, Subclipse does not Delete/Add, that is what
Subversion does under the covers when you do Move/Rename. Actually it
does Copy/Delete, but Copy is really just a special kind of Add.
The problem is that Subversion does not allow you to do what you are
trying to do. Neither does TortoiseSVN. Try them both and you will see.
You can enter an issue in our issue tracker if you would like. Ideally,
we could behave the way TortoiseSVN does and not allow the second rename.
It might be impossible to do this in Eclipse though since we are not the
ones that are contributing the rename actions to begin with. However,
presumably we can communicate to the refactoring mechanism that the rename
cannot proceed.
In your particular example what you should do is Revert. This will put
back the original file, and un-add the new file (preserving the mods). You
can then just manually copy the contents and delete the file you do not
want.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Apr 20 01:25:52 2005