In this posting I will attempt to build upon where I left off from my previous entry regarding SVN and Google's Project Hosting (GPH). My experience portrayed here will both reflect the ease and comfortableness of using SVN in a group oriented setting.
Experience:
My project is currently being hosted by Google's Project Hosting and all members of the project have SVN command privileges to add, delete, or commit changes. Likewise, I could also do a checkout of someone else's project using the same command ("svn checkout...") under "Source" tab in GPH. If I've been given membership to this person's main code line, then I'll also have full write access to their master repository. This means that the changes I make locally will reflect on the live repository once I perform a "svn commit -m...". I will attempt this very concept on a group member's project. After checking out the source from the member's repository, I am given a local copy of the project. Before attempting to run the program or make any changes of my own, I ran "Ant" to assure the code that I've just checked in, integrates well without error. If errors do occur, then I'll either have to notify the discussion group or make the changes myself.
Currently the project appears to be at a solid state without any conflicts or obvious errors. The actual error didn't occur until I used Eclipse and Ant simultaneously to execute tests and run verifications. It turns out that the given build.xml file provided by this project conflicts with Eclipse's class build directory path. Eclipse assumes ownership over a folder while Ant secretly writes to that directly after each build. Eclipse complains by throwing a "ClassNotFoundException". The easiest way to fix this is to create a folder in the project directory called "bin" and modify the default classpath in Eclipse to point to this directory. You can make this slight modification in Eclipse by going to "Project>Properties", under "Source" tab and change "Default output folder". At this stage, the current changes I make here are done locally and will not yet affect the main code line until I've committed. Now I will verify if my changes work for this issue by simply replicating the steps which brought on the error. Once everything seems to work with both Ant and Eclipse, then it should be safe to commit my changes. But before committing my changes, I'll first do an "svn update" to see if the project has changed since the time I was working on my fixes. This should be done before and after every commit to ensure that your code integrates well with other project member's code and to relieve later efforts of having to resolve more difficult conflicts.
Systematic procedures to keep integrity of code in-sync with master repository:
- svn update - brings your current local copy up-to-date with the current revision If conflicts need to be merged, then resolve these problems before continuing on.
- Make your changes on your local machine
- Run Ant's build tools to verify your code changes.
- svn update
- svn status - to see if the files you've modified are correctly marked with 'M'
- svn commit
-m "some informative message about the changes" - post changes to master codeline Continue the process again.
You can run the command, "svn log" to view the history of revisions made on the current project. Notice the last revision is listed first and its corresponding comments regarding the changes are made right below it. Also note that the optional commands like "svn log", "svn diff -r M:N filename", or etc. can be done easily on GPH's site. Its much more convenient and easy to read compared to using terminal. In my opinion, the most useful operation is svn's diff command. GPH provides a complete visual, including a side-by-side view of both files under different revisions. I only wish that GPH had a feature to produce patches along with having the ability to do diff's. Patches would be pretty useful for situations when you do not have full control over the master repository. So rolling out your own set of "diff" changes to fix a general project issue would be useful when you need to send it to a user group or mailing list to explain about your changes. From there your patches can be determined by the owners or other members, as to whether or not your patch should be applied to the main system. GPH solves the problem of communicating with members of the group project (via Google Groups), but does not make it easy for current members of the project to apply these patches/changes.
Conclusion:
Subversion is a code-management repository that enables you to keep your source code stored on a remote server (in this case Google's Project Hosting Server) that can be accessed by multiple members/users. Subversion makes collaborating with multiple users a breeze because users can checkout copies of the source code to their local machines, make edits, and then send the changes back to the SVN server. At that point, team members can update their local copies with all the team's changes. SVN manages the changes made to each file so that you aren't automatically overwriting your co-worker's work! Even if you are the sole developer, storing your project source under Subversion is a great way to keep a remote "backup" of your code in case your development machine is compromised or if you fall victim to a situation resulting in data loss.
No comments:
Post a Comment