Using Subversion for Collaborating in the development of eLearning Modules
It could get difficult to coordinate efforts on large teams of programmers, especially when it comes to version in a project that involves several eLearning modules.
Let’s suppose you have a team of five programmers and 3 of them are working in the same project, while the others are assigned to a different project or act as a backup, in case any issues come up for any of the main 3 programmers of the project, or in a better scenario, the client decides to add more eLearning modules to the project.
One option is to have a shared drive internally in the office where all programmers back up all their files (and this should be in place, as a best practice) but then, versioning can be a bit of an issue.
The other option is to use a subversion server or SVN, which not only creates backups of our eLearning project, but it also creates revisions of the files used in the project. This means, every time the programmers submit the files to the server, it doesn’t overwrite what’s in there, but creates a new revision of the file that can help when it is necessary unmake changes, as the programmes would then just rollback to a previous revision of that file.
Here is a diagram of how a SVN server works, in theory:
As seen in the diagram, a SVN architecture consists of a bidirectional communication between a server and a workstation (several workstations, in this case), in which the SVN server contains the head revision of our eLearning module and the workstations contain the working files (local files that can be modified and then be submitted to the server).
Let’s quickly define what head revision and working files mean:
Head revision: We can say it’s the main copy of the files. All the workstations check in and check out files from here.
Working files: Are the independent files stored in every workstation involved in the project.
The workflow of the SVN server can be briefly described like this, assuming all the services and tools are already in place:
Head revision is created. Here, the file structure is created in the server, and the main files are copied over.
Workstations connect to the SVN server and download the files.
Programmers check out the files (or lock for edition) they need to modify. A file that has been checked out by a programmer, becomes read-only for all the other members of the team.
Programmer modifies the file and saves it to the working copy folder.
Programmer checks in the file to the server. This means the file is submitted and a new revision is automatically created.
Programmers sync their files to the most current version.
Steps 3 to 6 are repeated until the project is finished.
The advantages of subversioning files, are that we have a more controlled environment for the files that are part of our eLearning project, we have revisions, which means we can rollback our files as much as to unmake changes and, anyone can connect to the SVN server and will automatically retrieve the most current version available in the head revision.
