Why to synchronize with SVN in Eclipse?
February 28, 2011 2 Comments
Today we had an interesting experience with SVN. I always thought SVN Update and Commit is safe way how to do stuff, that you have to either hit conflict or everything is merged without any losses. After so many years with SVN I was proved wrong. We create incremental diff files for our SQL model – and today both me and my colleague created the file with the same name. He committed first. I updated. I didn’t check that file (it was just one of many). I committed. And he complained I had overwritten his changes.
How could that happen? Why team synchronization in Eclipse helps? Why update didn’t complain in the first place?! Is SVN to blame? Why it never happened to me in Idea? Actually could it? Have I ever committed the same files created the same day along with my team-mate before? If not, can it happen in Idea too? (It doesn’t have the synchronization as you know it from Eclipse, remember.)
First test with Eclipse – we did it again. Synchronization warns you about conflicting incoming changes. But you can update without any punishment from SVN itself. You have to check the file. When you create a file in Eclipse it is not added locally to the repository (actually, many of Eclipse users don’t know SVN basics “thanks” to this). After the update it becomes locally added and you can clearly see the changes in quick diff – or in outgoing changes – IF you diff them that is. Why would you care when there is no warning, right? Normally it’s not expected two of you create the same file in the same time. The whole process looks like update without any problem followed by your modifications (like they were done afterwards).
This means you should avoid creating the same files (we actually don’t need daily SQL changes tracking – in the end we have to aggregate a lot of files when we’re about to release the next version) or be very careful – or use Synchronize feature before you update. Or check newly added files for differences (who would think about that!).
I check the behavior with Tortoise, just to be sure it’s SVN here cheating me and not Eclipse. I checked out the same project twice and added files to both versions. I didn’t add it locally to the repository in checkout A. Then I added it in the local version B, committed and updated local copy A. File showed differences against HEAD, but no conflict, no warning – except for info that the file was added (and came from the repository).
If you add the file locally to both copies, then conflict is detected and you have to resolve it. When you know your file will be committed sooner or later, that it indeed is part of the project, the best way is to add it locally as soon as possible. You can do this in Eclipse too with Team, Add to version control – but I didn’t find any preferences that would do it automatically.
You can safely rely on update and checkout with IntelliJ IDEA, because Idea typically adds the file locally right after the creation – unless you go against its suggestions, which is not rational (R is not capital :-)). Actually why should you? If you want to have the file in the SVN, there is no reason not to add it. Not to mention you can see nicely whether the file is “under control” or not.
Eclipse tries to handle it differently – I actually don’t like this way (with or without today’s incident, which I consider non-essential, really). I want to know which file is going to SVN and which one is not. Actually, not only know – I want to be the one in control. Of course, you are in control with Eclipse too – but much later. In Synchronization perspective you can remove the file from view. Again – none of my colleagues knows how to remove particular file from this view forever without using svn:ignore feature – which is (I hope you agree) stupid. You’re using SVN ignore (that is SVN’s mechanism) because Eclipse doesn’t make any difference between files locally added and files out of control.
I nearly wanted to finish – but now I realized that I haven’t specified the plugin we use for SVN in Eclipse! Subclipse was used – and if this problem is approached differently with the other plugin (can’t recall the name) let me know in comments and I’ll probably switch. Idea has SVN support fully built-in and you can have only single problem with that (from what I experienced). When we had some older Idea and I “upgraded” local repository version (using newer SVN client for instance) my Idea couldn’t commit or update anymore. But currently with Idea’s free community edition I don’t expect this problem to occur again. 🙂
Happy synchronizing, updating and committing with as few conflicts as possible. And even less wannabe-no-conflicts. 😉