Home  |  Latest News  |  Contribute  |  F.A.Q.  |  Account  |  Scripts | About
Search ASPNut:
 
ASP Reference
Server Variables
ASP Glossary
Related Sites

Free Components

HTML Reference
Web Colors
Entities
CSS Level 1
Encode/Decode
Glossary

Our Sponsors
ASP Nuke CMS
Free Auctions
PHP 5 Script
Funktastic Blog
ULost Directory
Team Task

 

 

 

 

 

 

 

 

 

 

 

 

An ASP Web Site for Version Control
8/23/2006 - Kenneth W Richards

I am wondering if it would be feasible to create a version control system using Active Server Pages. I'm sure a lot of people would ask: "Why in the world would you want to do such a thing?" The reason why is that it would provide a simple way for people to create a version control system without requiring a dedicated Unix Server to host it on. The price of dedicated server hosting is not cheap, whereas the cost of a shared Windows hosting account is relatively cheap.

Version Control Components

In order to determine whether it would be feasible or not depends on what qualifies as a version control system (VCS). For the unitiated, this system is a central repository for code and files that tracks changes to those files over time. The files usually comprise a software product that is being developed using collaboration for various different sources. Files are typically checked out from the remote server (the VCS server), edited locally, and then checked in to the remote server.

So the various components necessary for version control are:

  • Maintain a filesystem containing program code and media files
  • Provide the ability to check-out files from the server (download)
  • Provide the ability to check-in files to the server (upload)
  • Track changes (versions) of files that are checked in
  • Limit the access to files and folders based on user authentication
  • Keep a log of who made changes and when

1. Maintain a filesystem containing program code and media files

Since the web server is built upon it's own filesystem, we can simply utilize this feature to manage our version control filesystem. By using the built-in ASP component Scripting.FileSystemObject, we can completely manage all of the files.

Each project can be located within a seperate folder. Each folder can contain it's own "virtual filesystem". Meaning that the version control system will only expose files and folders within the specific project folder. This allows us to create an unlimitted number of projects (only limited by the storage provided to the website.)

2. Provide the ability to check-out files from the server (download)

Checking out files is a simple matter of downloading the file that is on the server. Anyone who has clicked a link to download a binary file such as a PDF document is aware of how this works. This is basically what a web server is designed to do so it is no real chore to accomplish this.

3. Provide the ability to check-in files to the server (upload)

When it comes time to checkin a file, that's when it gets a little more complicated. Active Server Pages doesn't provide a facility to handle file uploads. Your web host may provide FTP access to your server, but then how would your version control software monitor and detect new uploads and then process them when they arrive?

Most web hosts provide the use of an HTTP upload component such as ABCUpload. This works great and should be used if it is available. In other cases, we can process uploads using pure ASP script (without using any COM objects). It is server-intensive, slow and doesn't allow big file uploads so it should only be used sparingly.

4. Track changes (versions) of files that are checked in

A key feature of version control systems is to keep copies of every version of a file. A version is created each time a file is checked in with changes. The operator may view the contents of any version of a file. The VCS must keep a log of every change to a file. By doing this, the VCS can recreate any version of the file by undoing changes that were made to the current version.

In ASP, we can track changes by writing the changes to a database or by writing them to the local filesystem. In order to do this we need to compare the version being checked in with the most recent version in the version control. From this comparison, we need to determine what changes have been made and store them in a change log. Once the change log has been updated, we can overwrite the current file on the server.

Although not strictly required by our definition of a version control system, an operator may also choose to rollback a file to a previous version. This basically undoes the changes that were made via one or more checkins. In doing so, the history of changes that were made to the file will be forever lost. Why would you want to do this? It makes the list of changes cleaner when you go back and look at whats been changed on a file since there are less changes to see.

5. Limit the access to files and folders based on user authentication

In order to track which person made changes to a file in version control, we need to create a user authentication system. Normally, this consists of a username and password that are passed to the server at the time a file is checked out or checked in. The server first verifies the user credentials before allowing the operation to proceed.

Authentication for a web site can be done through the use of hidden form fields or query string variables that are passed with each web request. Since our checkin (upload) and checkout (download) are both done through web requests, we can easily append the user login information to the requests. It is then just a simple matter of comparing the login details with an access list (which can be stored in a database or a flat file).

6. Keep a log of who made changes and when

Keeping a record of changes done to the files is not that complicated. It simply a matter of attaching a file version with a user and date. This information can later be retrieved to generate a report detailing the changes that were made.

A useful utility is to pull up two separate versions of the same file and view the changes that were made between the two. This is commonly known as a "Diff View" and it can be easily integrated into the website.

Other reports that may be useful to have are: all activity by a particular user, filesystem browser indicating files currently checked out and when they were last modified, all activity for a particular file type. While the filesystem browser is pretty much required, all other reports are strictly enhancements to the system.

Summary

One of the most limiting features is that a lot of the popular IDEs provide the ability to access version control directly. By building a non-standard version control system, it forces users to rely on external tools to perform the checkout and checkin operations.

We have seen that is indeed possible to create a version control system using just an ASP website. Although there are definitely some challenges, among which are:

  • Performing file upload (checkin)
  • Tracking changes from one version to the next
  • Providing a convenient method of working on files (checkin / checkout utility)

It is definitely feasible to create a system such as this. The next question is: "Is this really something you would want to do?" It would require a lot of hard work. But anything worth having usually does.

<< Return Home

Orvado Technologies

ASP Nuke CMS
Free Open Source
Content Manager
HomeFix Boards
Home Remodeling
Message Boards

Contact Us | Contribute | About | Site Map



"Success is how high you bounce when you hit bottom." - General George Patton

©2010 San Diego Web Design - Orvado Technologies, All Rights Reserved
ASP Nut provides articles and reference documentation for Active Server Page developers.