ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Web application deployment with CVS

Updated on September 28, 2008

CVS is a popular version control system widely used by programmers around the world. With CVS, many programmers can work on the same project without having to manage who works in which files by themselves. Concurrent modifications in the same files are allowed and CVS merges the changes into the main version of the file. This feature avoid you having to redo an entire day of work simply because another person changed the same file.

Although version control systems are popular, it's frequently used strictly in the coding process. This leaves processes such as testing and deployment unattended, and organization create a parallel work flow for managing this processes.

This text is intended for showing the process, but some CVS knowledge are required, as CVS concepts and commands will not be widely explained, just cited.

CVS for deployment – when it applies?

CVS does not control automated building, unit testing or such. In a specific case, this is no problem. CVS can be used for deployment when:

  • The language used is an interpreted one. So, there is no need for compiling code.
  • The application in question is a web application. In this case, you have control over the environment your application will be run (once it's your own web server).
  • And of course, your server runs a platform capable of running CVS.

Unit tests (if you're using them) have to be into the repository, managed as any other file in the project. This is important, as their versions have to be in sync with the components being tested.

Spend some time doing the first installation with this process, even if it seems to be more complicated than simply upload all files using FTP. You'll see, the updates will be much more simply than that, and the control you get over which customer runs which version compensate the effort.

Preparing the environment

You will need to have SSH access on your web server and your CVS server needs to be accessible by it. If your CVS server is the same machine or is internet accessible you will not have problems. If it's installed inside your Intranet you may have an extra work, but is possible. Ask you system administrator (if not you) to establish a VPN between your web server and the internal CVS server. In this case they'll be visible to each other by its VPN-assigned IP address, not the public or the Intranet ones.

Once this requirements are met, all you have to do to install your application in the server is to checkout the module on the destination folder, as you would do on a development machine. After you do that, files will be transferred, but they'll have versions, and not simply exists. It will be specially useful when it's needed to update the whole application.

Controlling versions independently

What I have described in the previous section was needed for advanced version control, but alone you'll see it's almost useless. That's because you did a checkout of the whole module, but you did it in the main (trunk) version. It means that in any moment you can update it and get development version of that files, possibly not well tested or defective.

First thing you got to do is close well tested versions, meant for installation on production servers and then branch them. When you make a branch in CVS, you can work independently on this version, leaving alone the main version and vice versa. Then, you checkout or update the module on the server, but this time, specifying a branch. This will allow to check in files continuously into the main version and leave you installed versions intact. In the case of a bug, you can fix the branch version, update clients and leave trunk intact. Or even merge with to avoid duplicated work.

Install and update cycle

Suppose you have a test_app module you want to install on your web server. If you have the environment ready, you can:

  • Once you think the development version is OK, test it. If it's working well, make a branch. You can give any name, such as a date, version number that makes sense to you, or even any arbitrary name. But give a name that can help you identify in the future what is in the version. A branch can be created using cvs tag -b BRANCH command, being BRANCH your desired branch name.
  • Now you create the branch, you have an identical version of the module, but tagged with the version name you chose. If you did not make the checkout process on the server, do it specifying the branch. If you already did it, do an update. On the same way, you have to specify the branch. A branch can be specified in checkout or update using the -t parameter.
  • Continue to develop and integrate files into CVS. Note that even after you check in files into the main trunk, updates in the server (which is using the branch version) will not change any files.
  • When you want to update your module again, all you have to do is repeat the process. Make a new branch, update on server, keep developing on trunk.

Bug fixes in branch versions

A bug always can be found in a version that is already tested and on production. In that case, you may not want (most of the cases you'll not want) to fix the bug in the main version and do a full upgrade, as it can be slow and can lead to more bugs.

When it occurs, all you have to do is fix the bug on the trunk version, commit and then update on the server.

  • Checkout the files you have to change using the parameter -t BRANCH to inform CVS that you want that file on the version of the branch BRANCH. If you prefer, checkout the entire project on a separate directory, always specifying the branch.
  • Change it, and once tested and working, do a commit. The commit will affect only the branch.
  • Do a cvs update on the server. Your changes will be copied from the CVS server.
  • If the bug occurs on the main version, you can replicate the changes into the trunk. On a trunk version directory, run a cvs command -j BRANCH. It will merge changes from the branch into the files. Note that it will affect only your local files; you still have to check them in to put it in the repository.

Managing multiple installations on the same server

CVS stores the version information on files located into sub folders named (surprise!) CVS. Each folder managed by CVS have this sub folder, which some files inside it. This simplicity makes each directory not dependent on any system-wide file, or so.

That way, all you have to do to run multiple versions is to have each one in a different folder on server. Just take care not to share the same database configuration or any other sensitive information that have to be different between installations of the same application.


    0 of 8192 characters used
    Post Comment

    • dougmcunha profile imageAUTHOR


      7 years ago

      The method proposed in the article can also be applied to other version control systems, like SVN. You can use this approach in any version control system that supports tagging and branching.

    • profile image

      Brijendra Kumar soni 

      7 years ago

      CVS web is an very good application for project and file managemnt(Histort,tag,commit,checkout etc..)

    • manoharsinghbisht profile image


      9 years ago

      Good article..Using CVS, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.

    • profile image

      Anthony Damasco 

      10 years ago

      very helpful - thanks, - ill give it a shot


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)