Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Eclipse and Subversion: Project Source Control From Within the IDE : Page 2

Learn everything you need to know about integrated source control with Eclipse and Subversion. You'll be able to seamlessly manage source code and other shared files in your software projects.


advertisement

Managing Files Inside Eclipse with SVN

Once your files are managed by SVN, managing them is fairly simple. Files and folders have intuitive options accessible by right-clicking and then navigating down to the Team menu.


Eclipse SVN: Intuitive Menu Options (Left Side)
Click here for larger image

Figure 15. Intuitive Menu Options (Left Side)



Here are brief descriptions of the common tasks you will perform on a daily basis.

  • Update. Referred to as Get Latest or Checkout, the icon illustrates that this option will bring in updates from the repository to your IDE. Generally, only files that you have not changed locally will be updated, though I have seen exceptions to this, so it is best not to rely on your un-committed changes being preserved. If you want to update and preserve your un-committed changes, update at the file level or use the Synchronize with Repository option.
  • Commit…. This will commit your changes or new objects to the repository. Unless you locked the file before making changes, other users could have committed changes while you were working. If this is a possibility, use the Synchronize with Repository option instead first.
  • Add to Version Control. This will add an object to version control but not commit it. I personally never use this option.
  • Lock. This tells the world that you and you alone are working on this file at this time. Only lock a file if you really need to prevent others from touching it, and be sure to release the lock when you are done. While the lock can be over-ridden by power users, it is an annoying task to do so.
  • Show Resource History. This is useful to if you need to revert to an older version or go hunting for the person that didn't read this article and wiped out your last set of updates.

Except for Synchronize with Repository the other options are used less frequently and mostly by advanced users.

Don't Just Update, Synchronize!

Synchronize with Repository is what new users should choose in lieu of Commit and Update until they become more proficient with the tools and know the code base very well. Selecting Synchronize with Repository with prompt you to switch to the perspective, which I strongly encourage you to do, and to check the Remember my decision for convenience's sake. Synchronize with Repository will allow you to see all changes you have made and the changes that others have made.


Eclipse SVN: Team Synchronize Perspective
Click here for larger image

Figure 16. Team Synchronize Perspective

While the number of features in this perspective may seem overwhelming at first, they quickly become familiar and easy to use. In this perspective, double-clicking a file opens it in compare view. If an icon indicates conflicting changes, this is where you can decide to over-ride with your changes, the changes in the repository, or merge the changes. If you try to commit from another perspective and the object still shows the ">" icon with no error message, it is often because there is a conflict that can be found and resolved quickly from the Team Synchronize Perspective.

There is detailed documentation available at the workspace synch documentation page, though most users should be able to get by just from the interpreting the icons.

One tip about using the Synchronize with Repository option: If you later create an Eclipse project that contains different SVN projects as folders, only run Synchronize with Repository on the folders and not the full project. Selecting the full project will result in the Subversive trying to synchronize the entire repository from the root down since the actual project itself is not an SVN project.

Creating New Subversion Projects in Eclipse

Adding new projects is very easy. The only difficult part may be determining the repository structure, which is decision based on preference and source management requirements rather than technical limitations. The structure used in these examples is not meant to represent an ideal option; it is only one chose for convenience during the writing.

Right-click on the project to add and select TeamShare Project.


Eclipse SVN: Share Project Option Displays for Non-Managed Projects
Click here for larger image

Figure 17. Share Project Option Displays for Non-Managed Projects


Eclipse SVN: Select SVN as the Repository Type
Click here for larger image

Figure 18. Select SVN as the Repository Type


Eclipse SVN: Most Developers Will Add to an Existing Repository
Click here for larger image

Figure 19. Most Developers Will Add to an Existing Repository


Eclipse SVN: The Project Name Screen Shows the Full Repository Path to be Created
Click here for larger image

Figure 20. The Project Name Screen Shows the Full Repository Path to be Created

From this point on, you can do yes, yes, next, next, and so on. As noted earlier, comments are up to your own conscious or your team processes, whichever you follow.

Common File Handling Tasks

There are a couple of common tasks that, while not used on a daily basis, are handy to understand.

Moving Files

If you need to re-package files, there are several options. Simple moves can be accomplished by using the standard Eclipse refactoring menu and then checking in from the highest point in the tree of the changes. More complex moves are easier to check in from the Team Synchronize Perspective, keeping in mind the various dependencies involved, such as the folder needs to be in source control before the file within it. Also, you want to commit the new location before committing the old location, which is a delete. Large moves are more easily managed using the Refactor context (right-click) menu in the SVN Repository perspective. This perspective provides access to the full repository, so it is slower than the other options, but definitely safer if you are unfamiliar with moving files in SVN.

Managing Non-Source Files

More than just source control, Subversion is a handy place to store project files. Admittedly I was initially against storing documents in a source control application, but it had so many advantages that I changed my mind.

In many cases locked-down enterprise machines won't allow installing various file management applications or block the ports that such applications use. Often this does not extend to Eclipse plugins and the ports used by SVN.

To store documents and other non-source code files in Eclipse, it is easiest to create a single project in Eclipse for such items. If your repository is structured to manage these files then you can simply check out the relevant project. If not, you can create a generic project in Eclipse and then check out the non-code folders from SVN as Folders in a Project.


Eclipse SVN: Check Out as a Folder Is Handy for Non-Source Files
Click here for larger image

Figure 21. Check Out as a Folder Is Handy for Non-Source Files

Free and Low-Cost Services

Here is a listing of free SVN project-hosting services. I used XP-Dev only because I received a certificate error with Firefox at OpenSVN and sometimes need to access the repository from secure networks.

Those Pesky SVN Files

One thing I don't like about SVN is the .svn files it leaves behind. They use up a lot of disk space and make it a pain to migrate files from one machine to another outside of using SVN. This happens regardless of whether you integrate with your IDE or not. A couple of workarounds I have found to this is to export projects rather than copy them in the file system, and to use Robocopy with anything including .svn to be ignored (/XD *.svn).

One thing that people run into when they transition from managing their SVN repository from outside Eclipse is accidently importing the svn files into their projects. The simplest fix is to start a new workspace. If your build process picks up all files, you should configure it to ignore the SVN file.

Conclusion

If ignorance is bliss, I hope you have something other than source control from within your IDE to keep you happy. All kidding aside, they say it takes only three to seven times to make something a habit, so practice these tasks daily for a couple of weeks and you probably will forget ever having done differently.



Scott Nelson plays the roles of development manager, architect, project manager, and portal evangelist on any given day, and blogs lessons learned at Head in the Web when they are not suitable for Developer.com or DevX.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap