You should by now have completed the first four projects of the Hudzilla Coding Academy, which have given you a variety of fundamental skills in C# and Mono programming. If you're following this series with a tutor, it's now time to check you have learned everything fully, which means it's time for an assignment: a code project where you have to write the whole thing yourself.
Don't worry - I'm not just going to drop you in the deep end and hope you start paddling. I want to help you solve this problem yourself using the skills you have learned here. In fact, the whole point of these assignments is to let you check how much you've remembered from the previous projects, and also to give you a chance to adapt what you have learned to fit new programming problems.
To help you along, I'm going to give you some hints on how to solve various problems, but before I do that let's see what the assignment actually is...
Version control systems are common developer tools to help us keep track of our code as we write it. Put simply, you tell your version control system (VCS) which files you want it to track by adding and deleting files individually, then whenever you want to commit your modifications you just ask the VCS to save your changes.
To complete this assignment, you must produce SimpleVCS: a super-simplified version control system that tracks files changes, allowing developers to add newly changed versions of multiple files at a time, and also to revert back to any previous version.
More specifically, your VCS must do the following:
- Allow users to add files to version control using the commands "add somefile.txt", "add somedirectory" (which adds all the files and subdirectories inside that directory, recursively) and "add *.txt" (which adds all files in the current directory that end in .txt).
- Allow users to delete files from version control using similar syntax to the "add" command except with "delete" instead.
- Allow users to save changes when they run the command "commit". This should check all files under version control to see if they have changed, and, if they have, should back them up.
- Each time a commit is run, a new version number should be created to uniquely identify that commit, counting from 1 upwards. NB: this doesn't mean that each file has its own version number. Instead, it means that each commit has a version number, eg commit number 25 may have changed 10 files.
- When users run the "commit" command, you should prompt them for a log message. This should be saved somewhere so that the user can use a "log" command to see the message that was saved for each commit.
Some hints from Hudzilla
When you were reading through the description for this project, I'm hoping that our ChronoJohn project jumped into your mind - it certainly has a lot in common. The major difference this time, though, is that we don't care when files were changed individually - we only care when the programmer saved their changes. That means files don't have individual backups as they did in ChronoJohn, so you need to think in terms of commit revisions.
The way Subversion handles multiple directories is to have a ".svn" hidden directory in every directory it has under version control. You can go for that method or use ChronoJohn's path-within-a-path method whereby backing up /var/www to /home/hudzilla/backup would produce the directory /home/hudzilla/backup/var/www.
Reading in the log message should be easy if you've already completed the WorldScramble project. You can save the log message in one big text file if you like, similar to how Project One worked, or you can save each revision's log message inside a revision folder, and piece it together on the fly when the "log" command is received.
The commit command is one that should prove particularly interesting. If you're stuck, the easiest way to implement it is just to take a backup of every file regardless of whether it has changed, putting the whole thing into a directory named after the version number!
Finally, and most importantly: don't get discouraged if you find this project hard. It's supposed to be hard. It's supposed to put your skills to the test because, when you succeed, you'll have a much stronger grasp of everything you have learned so far. If you have any questions, email your tutor - they aren't allowed to provide any code, but they can at least help point you in the right direction if you're struggling.
The following are not required to successfully complete this assignment. You should only attempt them if you're really looking for a challenge.
- Add a "revert" command that rolls back to a previous version. If you're doing differential commits (ie, you save only the changes that were made), you need to roll back each version at a time.
- Add a "status" command that shows what has changed since the last commit. For example, if the file /home/hudzilla/foo.txt has been added, show "A /home/hudzilla/foo.txt". If a file has been modified show "M" and if a file has been deleted show "D".
Ready to submit?
Once your homework is finished and ready to submit, email it to your tutor. Remember not to include any binaries/executables - just the source code.
The small print
This work was produced for TuxRadar.com as part of the Hudzilla Coding Academy series. All rights are reserved.
You should follow us on Identi.ca or Twitter