Dude, I'd take a closer look at what really happens when you commit after a
refactoring. I think you'll find it works fine.
There is a "problem" in subclipse in that it shows things as deleted+added
instead of "renamed/moved" but it definitely does a move/rename on the
commit and the history is retained.
The only time you might have problems is moving a class between projects
because subclipse (apparently) does separate commits for each project when
files from more than one project are attempted to be committed. I'm not
sure of the side effects of doing this sort of move.
But definitely, a rename/move within the same project has no issues
whatsoever that I've seen, particularly in regards to retaining history,
I guess I should point out I'm using the javahl interface but I doubt the
command line one doesn't work, since refactoring has been a part of
subclipse for as long as I've been using it (>12months).
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: Thursday, 2 December 2004 5:18 AM
Subject: [Issue 187] New - no true refactoring support yet (svn
Summary:|no true refactoring support yet (svn
------- Additional comments from email@example.com Wed Dec 1 10:17:40
-0800 2004 -------
Using the great refactoring tools within Eclipse currently causes problems:
When renaming a Java class (PreviousClass => RefactoredClass), for instance,
refactored file is renamed in the local file system. However,
Subclipse/Subversion doesn't "know" that it's a refactored file, so it marks
PreviousClass file as to be deleted from the repository and adds
"RefactoredClass" as a new file (i.e. a file without "history"). That's a
step forward compared to the first versions of subclipse already, but
it would be great to provide real renaming/moving support within the
while keeping the file's subversion history.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Dec 2 08:48:43 2004