Re: Rename of Versioned Files
On Apr 20, 2009, at 4:55 PM, CodeWarrior wrote: 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 in Versions 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: The problem in Versions is not a software problem like a Bug, but that i need to do much think more than just use the Subeclipse, that i just rename inside the Eclipse and the SubEclipse plug-in do the remove normal.java and add the new file (normal1.java). Do u understand now? More work. I just want rename a file inside a eclipse and when open the Versions they automactic remove normal.java and add normal1.java How can Version do it, i don't know. What i'm say? That this is a very good feature that speed up our work, just it, not a Bug report or a Version software problem. You've still lost me. From what you've described in the thread, if people have Subclipse or Subversive installed, renaming inside Eclipse should work. With Eclipse by itself (no SVN plugins) it probably won't. This is totally normal behavior, not a bug in Subversion, Versions, or Eclipse. When you manipulate Subversion working copies, somehow you have to tell Subversion that you're making changes, it can't (and shouldn't) just guess what changes were made. It can be very tricky to tell if a file was moved to a different directory, renamed, or just deleted and a very similar file was added. With no offense intended, if your developers do the right thing, everything will just work. If they want to rename resources that are in Subversion from within Eclipse, they must install a Subversion plugin. (Why Eclipse comes with a CVS plugin by default, but not one for SVN yet is beyond me. It would make life easier for a lot of people.) In my experience, when you have the proper plugin installed and rename in Eclipse, there aren't any problems. I'm not sure exactly what symptom you're seeing in step 9 (everything is not alright) back in Eclipse, but it sounds like renaming in Eclipse avoids the problem. If your developers are using Versions (which they had to download, install, and configure), what's keeping them from taking 5 minutes to install Subclipse/Subversive? If that solves the problems you're having, it seems like a no-brainer. I think this is the feature you're looking for to speed up your work.:-) - Quinn smime.p7s Description: S/MIME cryptographic signature
Re: Rename of Versioned Files
Quinn, forget :) Thankx for your answer. -- The Future Begins Today Em 21/04/2009, às 12:18, Quinn Taylor escreveu: On Apr 20, 2009, at 4:55 PM, CodeWarrior wrote: 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 in Versions 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: The problem in Versions is not a software problem like a Bug, but that i need to do much think more than just use the Subeclipse, that i just rename inside the Eclipse and the SubEclipse plug-in do the remove normal.java and add the new file (normal1.java). Do u understand now? More work. I just want rename a file inside a eclipse and when open the Versions they automactic remove normal.java and add normal1.java How can Version do it, i don't know. What i'm say? That this is a very good feature that speed up our work, just it, not a Bug report or a Version software problem. You've still lost me. From what you've described in the thread, if people have Subclipse or Subversive installed, renaming inside Eclipse should work. With Eclipse by itself (no SVN plugins) it probably won't. This is totally normal behavior, not a bug in Subversion, Versions, or Eclipse. When you manipulate Subversion working copies, somehow you have to tell Subversion that you're making changes, it can't (and shouldn't) just guess what changes were made. It can be very tricky to tell if a file was moved to a different directory, renamed, or just deleted and a very similar file was added. With no offense intended, if your developers do the right thing, everything will just work. If they want to rename resources that are in Subversion from within Eclipse, they must install a Subversion plugin. (Why Eclipse comes with a CVS plugin by default, but not one for SVN yet is beyond me. It would make life easier for a lot of people.) In my experience, when you have the proper plugin installed and rename in Eclipse, there aren't any problems. I'm not sure exactly what symptom you're seeing in step 9 (everything is not alright) back in Eclipse, but it sounds like renaming in Eclipse avoids the problem. If your developers are using Versions (which they had to download, install, and configure), what's keeping them from taking 5 minutes to install Subclipse/Subversive? If that solves the problems you're having, it seems like a no-brainer. I think this is the feature you're looking for to speed up your work.:-) - Quinn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: Rename of Versioned Files
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: - About it: The problem in Versions is not a software problem like a Bug, but that i need to do much think more than just use the Subeclipse, that i just rename inside the Eclipse and the SubEclipse plug-in do the remove normal.java and add the new file (normal1.java). Do u understand now? More work. I just want rename a file inside a eclipse and when open the Versions they automactic remove normal.java and add normal1.java How can Version do it, i don't know. What i'm say? That this is a very good feature that speed up our work, just it, not a Bug report or a Version software problem. Obrigado. -- The Future Begins Today Em 18/04/2009, às 11:49, Quinn Taylor escreveu: 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 +
Re: Rename of Versioned Files
We're talking about the same thing. When Versions displays the state of your working copy — including what has been modified, added, deleted, renamed, etc. — it's just a graphical view of information that you can view using the `svn status` command. When Eclipse or Versions renames a file, it actually performs the equivalent of `svn move old/path/name new/path/name` on the working copy. This is what makes it possible to use different SVN tools on the same working copy. The problem comes in when one tool doesn't do exactly what it's supposed to. I'm not saying that Versions is always right (after all, it is a newish product, and quite a few bugs have already been squashed) but my experience is that when I rename using Terminal or Versions, the 2 tools have always been in sync. Same with Xcode, as far as I can tell. That's why I suppose I'm suspicious of Subclipse in this case. If you made the change inside Eclipse, and Versions doesn't display what you'd expect, always turn to Terminal to see if the most basic SVN tools agree with Eclipse or not. That will help you know if the rename is being done correctly. Espero que isso ajuda, - Quinn On Apr 17, 2009, at 9:25 PM, CodeWarrior wrote: Quinn Thankx for your answer but i'm not the programmer and not the admin, what i need is not know the status, but rename inside eclipse and Version automatic detect it and rename the file in the SVN and NOT appear missing. It's possible? Obrigado. Em 17/04/2009, às 17:13, Quinn Taylor escreveu: The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add-with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! smime.p7s Description: S/MIME cryptographic signature
Re: Rename of Versioned Files
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 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. 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. 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. Obrigado! -- The Future Begins Today Em 18/04/2009, às 03:16, Quinn Taylor escreveu: We're talking about the same thing. When Versions displays the state of your working copy — including what has been modified, added, deleted, renamed, etc. — it's just a graphical view of information that you can view using the `svn status` command. When Eclipse or Versions renames a file, it actually performs the equivalent of `svn move old/path/name new/path/name` on the working copy. This is what makes it possible to use different SVN tools on the same working copy. The problem comes in when one tool doesn't do exactly what it's supposed to. I'm not saying that Versions is always right (after all, it is a newish product, and quite a few bugs have already been squashed) but my experience is that when I rename using Terminal or Versions, the 2 tools have always been in sync. Same with Xcode, as far as I can tell. That's why I suppose I'm suspicious of Subclipse in this case. If you made the change inside Eclipse, and Versions doesn't display what you'd expect, always turn to Terminal to see if the most basic SVN tools agree with Eclipse or not. That will help you know if the rename is being done correctly. Espero que isso ajuda, - Quinn On Apr 17, 2009, at 9:25 PM, CodeWarrior wrote: Quinn Thankx for your answer but i'm not the programmer and not the admin, what i need is not know the status, but rename inside eclipse and Version automatic detect it and rename the file in the SVN and NOT appear missing. It's possible? Obrigado. Em 17/04/2009, às 17:13, Quinn Taylor escreveu: The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add-with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups
Re: Rename of Versioned Files
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
Re: Rename of Versioned Files
The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add- with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! -- The Future Begins Today --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
Re: Rename of Versioned Files
Quinn Thankx for your answer but i'm not the programmer and not the admin, what i need is not know the status, but rename inside eclipse and Version automatic detect it and rename the file in the SVN and NOT appear missing. It's possible? Obrigado. -- The Future Begins Today Em 17/04/2009, às 17:13, Quinn Taylor escreveu: The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add-with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! -- The Future Begins Today --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
