Home/ Questions/Q 635535
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T20:24:54+00:00

I am using SVN for source code management on a Classic ASP app that

  • 0

I am using SVN for source code management on a Classic ASP app that I develop/support. I maintain several versions of the app as required by my company:

  • Discovery/playground version – where I do all the work. My Working Copy
  • Dev/Test versions (no access to these sites/servers)
  • Live version (no access to these sites/servers)

Here is when I run into trouble:

  1. Work is done on Project A and is committed
  2. Project A is promoted to Dev/Test using an export from the log
  3. There is a problem with Project A and it is stalled in Dev/Test
  4. Project B comes along, is prepared and committed
  5. Project B now builds on Project A, but there are parts of Project A not ready for prime time

Short of just “be careful not to screw anything up,” is there anything I can do to make sure that parts of projects can stall in the development process without holding up everything?

The necessity of a web server in the process seems to be causing me problems. I know that I can branch Project A when it goes to Dev/Test, and then merge it back to the trunk when it is live. Also that way I can revert my playground from before the branch and do Project B without anything from Project A having a chance to go live accidentally. However, then I can’t play with Project A on my playground site. Do I have to spawn a new playground site for each branch?

I know that this is probably too specific to my situation with all its constraints, but I’m hoping somebody else has experienced something similar to my situation.

Thanks!

EDIT:

Here is my current solution: Maintenance fixes – changes that could go immediately to production – can get made in WC and committed to the trunk. Anything that has dependencies on a project gets branched. Working copies along the test path can be switched to point to that branch to test a project. Branches have to be kept up to date, and we can use commit hooks to keep people notified. When a branch is ready to be deployed to production, it gets merged back to the trunk and deployed.

This makes sense and would work, right?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We control our code base with one instance of SVN and use another to control the environments and the contents of the web servers for each testing stage and eventually production. Having the history of what has been on each environment has saved us a number of times. Keeping your log messages meaningful will definitely pay off.

    I export from the automatic build sent to our Dev server onto a checked out version of the System Test files and then commit the changes to that. Updating the servers in the web farm is just a case of updating to the HEAD revision on all the boxes. Staging is updated using an export from System Test and then Production is finally updated from a Staging export. Some parts of this are scripted but having manual oversight is convenient. Probably the hardest bit is ensuring the config files are correct for each environment but if you aren’t changing it you don’t deploy it.

    You will probably still want to get to grips with feature branches or release branches and the necessary strategies to recombine the source. You may need to bug-fix something in Production you never expected no matter how good your testing strategy.

    One thing to note is not using client version 1.6x with a 1.5x SVN server as this is playing havok with our merge processes until we upgrade see; http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx

    EDIT:

    Each server in our deployment environment has the TortoiseSVN client installed so that the sysadmins have a GUI for updating the checked out repository.

    I have also made them some scripts that use the SVN command line utilities to update a few repositories on the servers with an automated job. This allows our content team to commit files to their local copies of the server resources folder and then this updates every hour. They only have access to a that specific set of folders which we control with the auth file on the SVN server.

    We have two separate machines that actually have SVN server installed which are backed up daily. One is for repositories of source code and the other one for the eventual builds that are deployed in each environment. It does mean we have a complete duplicate repository for the deployment in each environment but storage isn’t an issue.

    • 0