On Apr 18, 2009, at 12:06 AM, CodeWarrior wrote:
Thankx Quinn. I will check with the admin of company. Just for check, i will post what happens: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, you will see that the Version says that the normal.java is missing
This is as expected, because Eclipse has only renamed the file in the file system, but knows nothing about Subversion, so any svn tool will show "normal.java" as missing and "normal1.java" as a new, unversioned file. (The same thing would happen if you just renamed the file in Finder.)
What i want (to know if Versions do): 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, they will detect that normal.java is now normal1.java 5 - Versions actualize the svn and everything is alright.
Please don't expect this to happen without using Subclipse or Subversive. It's easy to think that Subversion should "just know" what you want to do, but it doesn't. You have to specifically tell it somehow.
What happens with Subeclipse: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Subeclipse and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (with subeclipse, rename it to normal1.java 4 - Its automatic renamed in svn. normal.java is deleted, normal1.java is the new normal.java versioned 5 - everything is alright.
This is as expected. If Subclipse/Subversive knows the file is in an SVN working copy, it can rename the file properly. (By "everything is alright", I assume you mean that Versions and any other SVN tool sees and recognizes the file rename as valid.)
What we are doing now: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - You discover that normal.java need to be normal1.java 4 - Open the Versions, go to the svn and rename (manually). 5 - Go to the trunk that was checked out and update 6 - normal.java is now normal1.java 7 - Inside the eclipse refresh the project, now, normal.java is normal1.java 8 - open normal1.java and correct the type name 9 - everything is not alright Now, i just need to know if Versions do the same of Subeclipse, i need a smart svn tool that reduce clicks and accelerate the job of my team.
This is where you've lost me. In step 4, I assume you're right- clicking on the file and selecting "Rename", then typing the new name. Yes, Versions does this correctly. If you're renaming the file in the working copy (which is recommended, so the developer can resolve any build errors before committing) and you run svn status (in Terminal) at this point, you'll see the following:
$ svn status D normal.java A + normal1.java(This matches the + and – icons that Versions displays.) This is how SVN models a rename: a delete and an "add with history". This is how the revision history of normal.java is linked with normal1.java after it has been renamed. NOTE: It's generally a good idea to rename the Java class inside the file before committing, as well.
So, Eclipse is picking up the name change for the file, which means the file was successfully renamed in Subversion. So, what happens in step 9 that "is not alright"? Build warnings/errors in Eclipse? A crash? After reading your more detailed description, I'm more likely than before to point the finger of blame at Eclipse. Although it's a powerful tool with lots of handy features, sometimes it can be a real pain in the neck to deal with. Since the file has actually been renamed in Subversion, (you can tell because it changes after updating your Eclipse working copy), it doesn't seem like a problem with Versions at all, but rather how Eclipse is responding to changes done in Subversion rather than its own editor.
Perhaps a little more detail on the specific problem you're seeing in Eclipse after the rename can help pinpoint the problem?
Boa sorte, - Quinn
smime.p7s
Description: S/MIME cryptographic signature
