Working with TortoiseSVN and Google Code Projects
| Posted on Wednesday, October 08, 2008 |
2
commentsAdd comments |
This week I began working with TortoiseSVN, “The coolest Interface to (Sub)Version Control” according to its web site. TortoiseSVN provides remote access to code files for the management of the collaborative efforts by a developer group working on a project.
The project used to familiarize myself with TortoiseSVN usage was stack-johnson. This project is remotely hosted at Google Code. Stack-Johnson is a basic stack implementation developed by my software engineering professor Philip Johnson at the University of Hawaii at Manoa.
Learning the Ropes
TortoiseSVN simplifies the tasks of subversion control to a great extent versus using command line arguments, so I appreciated not having to work from the MS-DOS shell. After setting up a C:\svn-google directory from which to work with the code repository files for the stack-johnson project, it was a simple task of checking out the project files. Since TortoiseSVN is a GUI application that is accessed directly from the Microsoft Explorer short-cut menu, it was just a matter of selecting SVN Checkout... from the menu. To complete the checking out of the files requires the user to enter his username and password needed, which is provided by Google Code from the user’s Profile > Settings tab.
The first step any contributing developer wants to take after checking out project files is a check of the build status. In this case, I ran Ant against the verify.build.xml file to ensure the build was still viable from the updates other developers have been contributing to the project.
To understand the edit and checking in aspect of subversion control, I made a minor change to the project by restating the
Checking files back in becomes a simple task as well in TortoiseSVN. Again from the short-cut menu provided by Microsoft Explorer, I selected SVN Commit... to upload the changed
On My Own
With a comfortable feel from the successful use of TortoiseSVN’s basic operations and familiarity with Google Code’s remote project hosting site, I decided to embark on my own. If you’ve been keeping up with my blogs, you should know that I have been working on a similar project to
Setting up a remotely hosted project on Google Code in itself is not a difficult task, however, there are some pitfalls to watch out for. I had initially gone through the steps of setting up my
This wasn’t at all what I had wanted, and not knowing for certain if just recreating the accidentally deleted subdirectories in the local repository that I would be uploading to Google Code would be adequate, I decided to delete the project and start anew. Well, this only maked matters worse. First, projects are only flagged to be deleted, and that deletion is scheduled for some undetermined future date and time. This meant that even if I had wanted to recreate the
I decided to do some quick searches in the help function provided by Google Code only to discover that even once a project is deleted (by Google Code personnel) that the project name would still be unavailable. I found this completely frustrating that not only was I unable to delete the project as the project owner, but I wouldn’t be able to reuse the project name once it actually gets dropped from the hosting site.
I went through the process of creating another new project,
Conclusion
Overall, there were no major challenges to using TortoiseSVN or Google Code. The GUI interface and integration of TortoiseSVN in Microsoft Explorer makes it a trivial learning task for experienced users of the Microsoft Windows OS. Google Code is adequate for a free, open source project hosting site, but it appears to me that one of the main challenges it faces is resolving the issue of providing project owner’s true administrative rights.
The project used to familiarize myself with TortoiseSVN usage was stack-johnson. This project is remotely hosted at Google Code. Stack-Johnson is a basic stack implementation developed by my software engineering professor Philip Johnson at the University of Hawaii at Manoa.
Learning the Ropes
TortoiseSVN simplifies the tasks of subversion control to a great extent versus using command line arguments, so I appreciated not having to work from the MS-DOS shell. After setting up a C:\svn-google directory from which to work with the code repository files for the stack-johnson project, it was a simple task of checking out the project files. Since TortoiseSVN is a GUI application that is accessed directly from the Microsoft Explorer short-cut menu, it was just a matter of selecting SVN Checkout... from the menu. To complete the checking out of the files requires the user to enter his username and password needed, which is provided by Google Code from the user’s Profile > Settings tab.
The first step any contributing developer wants to take after checking out project files is a check of the build status. In this case, I ran Ant against the verify.build.xml file to ensure the build was still viable from the updates other developers have been contributing to the project.
To understand the edit and checking in aspect of subversion control, I made a minor change to the project by restating the
getIterator() method declaration in class ClearStack. It was a trivial change, but this allowed me to see some of TortoiseSVN’s visual cues it provides to developers. Upon checking out of project files, TortoiseSVN flags the files with a green checkmark icon in Microsoft Explorer. Once a file has been edited by a developer that icon gets changed to a red exclamation point. This visually identifies the files or directories the developer needs to check in to the repository.Checking files back in becomes a simple task as well in TortoiseSVN. Again from the short-cut menu provided by Microsoft Explorer, I selected SVN Commit... to upload the changed
ClearStack.java file to the stack-johnson remote repository. Again this process will prompt the user to provide his username and password, however, the user has the option of having his password retained by TortoiseSVN eliminating the task of needing to retrieve the unique and random password assigned by Google Code.On My Own
With a comfortable feel from the successful use of TortoiseSVN’s basic operations and familiarity with Google Code’s remote project hosting site, I decided to embark on my own. If you’ve been keeping up with my blogs, you should know that I have been working on a similar project to
stack-johnson. That project is my stack-reeves project which I have been working on over the past few weeks as I have journeyed through the exploration of coverage testing and manual and automated quality assurance methodologies.Setting up a remotely hosted project on Google Code in itself is not a difficult task, however, there are some pitfalls to watch out for. I had initially gone through the steps of setting up my
stack-reeves project. This had gone smoothly until I decided to reset my project from the Source tab. This caused all the subdirectories to be deleted from the project. I had not uploaded my project files yet, but it caused the branches, tags, and trunk subdirectories to be deleted. There was no direct way to recreate the subdirectories or undo the operation, so I only had an svn directory.This wasn’t at all what I had wanted, and not knowing for certain if just recreating the accidentally deleted subdirectories in the local repository that I would be uploading to Google Code would be adequate, I decided to delete the project and start anew. Well, this only maked matters worse. First, projects are only flagged to be deleted, and that deletion is scheduled for some undetermined future date and time. This meant that even if I had wanted to recreate the
stack-reeves project that I’d need to wait for the personnel at Google Code to drop the project first.I decided to do some quick searches in the help function provided by Google Code only to discover that even once a project is deleted (by Google Code personnel) that the project name would still be unavailable. I found this completely frustrating that not only was I unable to delete the project as the project owner, but I wouldn’t be able to reuse the project name once it actually gets dropped from the hosting site.
I went through the process of creating another new project,
stack-ronnreeves and ensured I made none of the mistakes that led to my befuddlement in my first attempt. The stack-ronnreeves project can be accessed here.Conclusion
Overall, there were no major challenges to using TortoiseSVN or Google Code. The GUI interface and integration of TortoiseSVN in Microsoft Explorer makes it a trivial learning task for experienced users of the Microsoft Windows OS. Google Code is adequate for a free, open source project hosting site, but it appears to me that one of the main challenges it faces is resolving the issue of providing project owner’s true administrative rights.
