This entry assumes that you are using Eclipse, Subversion, the Subclipse plugin for Eclipse, and TortoiseSVN (Windows). There are Mac SVN clients available as well, such as SCPlugin.
You may find a wealth of information and links related to Eclipse, Subversion, Subclipse, and SVN Clients (and a whole lot more) over at Simeon Bateman’s Blog.
I also recommend that you check out the docs: SVN Book
There are several ways to approach setting up your project in the SVN repository. In this example I am taking an existing project and setting up a new versions folder in the repository; as of yet I have not created any folders in my repo other than just my project folder. What I want when finished is to create three folders inside my project folder named branches, tags, and trunk. The trunk folder will contain my working copy, the tags folder will contain my release candidates and production version(s), the branches folder will contain branches of code which may or may not ever be incorporated into the tags versions.
Don’t get confused with the difference between branches and tags; there really is no difference other than where they are located and their intended purpose. For instance, as I mentioned that the tags folder holds production and release versions; the branches folder simply holds versions that might be experiments, broken code, vendor versions, and anything else that does not belong to the other two folders.
Creating Folders in the Repo
Using the SVN Repository Perspective (you could use Tortoise for this), open the repository which contains your project folder (Window>Open Perspective>Other>SVN Repository Explorer). Right click within the explorer pane and select New>New Remote Folder (if you have not created your project folder in SVN yet then do so now using the same
project name, place the project folder under the main repo folder so you have a folder to create your trunk, tags, and branches folders). Note – you will need to refresh the repo explorer to view your new project folder. In the New Remote Folder dialog, expand the repo which contains your project folder and select your project folder as the parent of the folder you are about to create. In the folder name field, name your new folder “trunk” and click next. In the commit message dialog, provide a description of the commit (e.g. Create Trunk Folder) and click “Next”. Do the same thing two more times in order to create the “tags” and “branches” folders.
This completes setting up the repo for your project.
Placing Your Project into the Repo
Now we need to place our project into the trunk folder, this is going to be your main development working copy folder. This is where I use Tortoise as at this time I am not aware of a way to copy files and folders from the file system into the repository using the SVN Repository Explorer. From your desktop, right click on any open space of your desktop and hover on TortoiseSVN, choosing “Repo-browser” from the flyout. Select your project repository from the “URL” dialog and press “OK”. Expand your project to view the folder tree which we created. Leaving the Repo-browser window open, navigate to your project folder on your file system in a separate window. Drag your project from the file system into the “trunk” folder which we created, found in the Repo-browser under your main project folder. Enter a log message to document the addition of your project from the file system to the Repository and choose “OK”. Expand your trunk folder to find your project folder contained within. Whoo-Hoo! We now have a project in the Repository Trunk Folder. We still have some more work to do before we can begin working with our version control copy.
Actually Using SVN
Up to this point we have made a nice backup of our project in the version control repository, but we still need to be able to work from our new working copy. The following is not for the faint of heart, well its not that bad. At this point I recommend making a quick backup copy of your project. Simply make a copy of your project on the file system to another folder, such as your Desktop, to temporarily store a safety copy (you could copy to disk or another drive if that makes you feel better). Let’s return to Eclipse in the Navigator view, right click on your project and select “Delete”. That’s right, I said delete your project, no worries, this will make sense in a minute. From the “Confirm Project Delete” dialog, choose “Also delete contents under [your path]” so we can completely remove your project from the file system. Choose “OK” – Gasp… Ok, remember to breath – it is a really important activity. Before you fall over, open your SVN Repository Explorer in Eclipse, open your project folder in the repo, and expand your trunk folder. Whoa…that was better than the tilt-n-hurl at your local summer carnival. As you can see, I hope, your project is safe and sound in your trunk folder. If not, no worries – you did make a backup like I instructed – right?
Checking Out a Project From the Repository
Now it is time to get our project back into Eclipse. This time, though, we will be checking out a copy from the repository into our file system which will serve as our local working copy. Right click on your project folder from within the trunk folder in the Repository and choose “Checkout”. In the “Checkout From SVN” dialog, review the default selections (“Checkout as project in the workspace”, “Project Name”, and “Head Revision”). Choose “Next”. In the “Check Out As” dialog, be sure to select the correct workspace if not the default location and create your new project folder using the “Browse” button to navigate to your workspace, creating a new project folder in the workspace for the project which is about to be checked out. Ensure that your folder name appears in the Folder field of the “Browse” dialog and click “OK”. Double check the Checkout location in the “Location” field, repeat choosing the correct location if this is not where you intended to place the checked out version. Once you have the correct location selected, choose “Finish”. Return to your Navigator view and refresh, if needed, in order to view your checked out project copy. Notice the path which has been amended to the end of your project folder. This is the Repository location for which the working copy is attached. When you make future edits and commits to the repository, this path will tell you exactly which copy is being updated in the Repository.
Excellent, we now have a working copy under version control!
Congratulations!
Committing Changes to the Repository
Now, as you continue to develop and/or maintain your project, you will want to make regular commits to the repository which represent various changes to your project. The cool thing about SVN is that you can commit as often as you like and still be able to revert back to any version which has been committed in the SVN history. So yes, you can revert back to a stable version should things ever go awry. So go ahead and make a simple change to your project, add a comment or something just so you have a change. Once you save your change notice the small black icon with an asterisk inside next to the file and containing folder where the change was made. This provides a nice visual as to what changes exist locally as compared to the Repository version. Also note that unchanged files have a small gold cylinder next to them which denotes that the local copy and repository version are synchronized. Now that you have made a change, a commit may be made to the repository. Again, right click on your project, or if you just want to commit a single file then you can right click on that file or even in the code view to select only that file for commit. Mouse down on “Team” to expand the SVN options and choose “Commit” located near the top of the menu. In the Commit dialog, document your changes by entering a log message which describes the change. Ensure that the modified files for which you would like to commit changes are checked and then click “OK”. Your changes are now updated in the repository, note the change of icon next to your files – they should all now be gold cylinders.
Right on, you just committed your changes to a new version. Also note the numbers which appear to the right of your file and folder names. These indicate the current revision number. Possibly you might be asking, “How can I make my version numbers something like 1.01, 1.02, etc…?”. The version numbers which relate to the repo are actually not related to release or branch versions, these are actually created by you when you create a tag or a branch version and become part of the folder name which contains the tag or branch copy. So don’t worry about SVN version numbers, they only provide an index to changes in the Repo.
Reverting to a Previous Version
Reverting is about as easy of a process as it gets. You may decide to revert to a previous version for many reasons; possibly you have made some changes which, for whatever reason, you decide to abandon. In order to revert local current changes, right click on the project folder, sub-folder, or file for which you wish to revert. Mouse over “Team” and select “Revert”. From the “Revert” dialog, select the files which you wish to revert and choose “OK”. Done! If you do not have any current local changes but wish to revert to a previous version then the process is just a bit different. Choose “Show History” from the team menu, right click the revision in the History view which you wish to revert to (this is a good example of why commit log messages are so important), and choose “Revert changes from revision [#]“. Choose “OK”. Notice that your local version is now different from the repository version, denoted by the icon next to changed files, if you would like to keep this revision then simply commit the change. If you would like to abandon this change then simply follow the former revert process.
Creating Tags and Branches
The process of creating a tag or branch is the same, and very similar to committing. As mentioned earlier, creating a tag is useful for creating separate versions, apart from the trunk, which serve purposes such as maintaining release versions for production. Branches are useful for creating versions which represent changes which may or may not ever make it to production but contain something of value which you wish to save. Perhaps you have some experimental code which you do not wish to abandon but just does not fit into the production project. Possibly a vendor, who’s code your application is based upon, issues maintenance updates which you wish to incorporate into your trunk to eventually be tagged for production release (vendor branches). Regardless, the only difference between the processes is where the files are placed – the tags folder or the branches folder.
In order to create a tag, or branch, select “Branch/Tag” from the team menu. In the “Copy Branch/Tag” dialog, review the “From” field to ensure you are branching or tagging the correct working copy; in the “To” field, make sure that the correct folder, branches or tags, is displayed in the path. If not, use the “Browse” button to navigate to your branch or tag folder where you would like to create the branch or tag. If you would like to create a special folder which designates a version, then you can simply append a new folder to the end of the To URL (i.e. myPath/RC_1.0). This will then be created for you. Select the revision which you would like to copy (i.e. “Head revision in the repository”, “Specific revision in the repository”, or “Working copy”.
Create a message in the branch/tag comment area. If you would like to continue to work in your current working copy then leave the “Switch working copy to new branch/tag” checkbox clear. If you would like to switch so that you can make additional modifications to the branch/tag without changing the current working copy then select this checkbox.
Click OK in order to create the branch or tag.
Open the SVN Repository Explorer, right click on the branches or tags folder for which you just created a branch or tag, and choose refresh. Your new branch or tag version should now appear within that folder.
Using “Switch to another branch/tag” in the team menu, you may switch working copies at any time by selecting versions from any of your project folders in the Repo. Be careful here as it is easy to inadvertently forget to switch back and end up making changes to a branch when you intended to change the trunk. You can always see where your working copy is connected by viewing the location in brackets next
to the project folder in navigator view.
There is allot more
I have only discussed a few of the most common SVN tasks using Subclipse and Tortoise. There are many more tools available in the Team dialog. Possibly I will discuss more of those in the future. One which I do wish to follow up on is the process of Vendor Branching using the merge process. This is a most useful process but can be complex and has
some important rules related to version history.
Please feel free to comment on your SVN methods/experience(s) and letme know if you have any questions, corrections, or comments about this entry.
Subversion Eclipse VersionControl
Note – this was a repost due to db issue. Subscribers – please forgive the multiple entry email.
Loading ...
