I have created a system for easily updating and deploying cvp apps to the server, as well has handling versioning. I though I would share it here for your benefit and for review/critque.
 
I make use of git-scm & gitolite to do this. 
Git: http://git-scm.org/ 
gitolite: http://sitaramc.github.com/gitolite/index.html
 
Gitolite is not necessary, it just makes controling who has access to the applications much easier. I will not go into the gitolite install process here, you can find that easily enough. 
I set this up with a linux box to host the git projects, but you could do it with windows if you prefer.
 
Setup is rather simple. 
You will need to have open-ssh installed on the CVP Server. This can be installed through cygwin. You will need a user on the CVP machine who is given ssh access. This user needs to be set up with ssh key authentication, to be used from the git host machine. When you install cygwin, install git with it.
 
Your gitolite config also needs user(s) for the CVP boxes. You can use one user for each machine or share the same user, it does not matter greatly.
 
Also, the SAB (stand-alone application builder) included with call studio needs to be placed on the CVP Servers. Place it in the root folder of the C drive, or update the paths in my scripts accordingly. Make sure that the plugins directory includes any custom elements you use, or the application will fail to deploy.
 
You may have to fiddle around a little to get file permissions and ssh working if you are not familiar with how cygwin works with windows. It took me a little while, but once it is setup you shouldn't have to mess with it again.
 
The two scripts that are needed are attached.
Place 'post-receive' on the git server box in <gitolite user's home>/.gitolite/hooks/common
Place a copy of 'gitUpdate.sh' in the SAB folder on each of the CVP servers.
 
Once those are in place, you can then create some git repositories out of your Call Studio applications. Install git on whatever machine you run call studio on, and update your gitolite-config with keyfiles for your user on the machine. Open a git-bash prompt on the folder of one of you call studio applications, and type 'git init' to initalize it as a git ptoject.\
Add the git server as a remote with 'git remote --add origin <gitoliteuser>@<gitserver>:ucceApps/<applicationName>'
 
Then, 'git add -A' to add all new, modified, or deleted files to the repository
'git commit' to save the changes to the repository. A vi editor will open, type a commit message about what you are doing.
Next, add the Live tag to your current commit 'git tag Live'.
Then, push your changes. The full command for this is 'git push <remoteName> <localRef>:<remoteRef>'. So, this first time, you would type:
'git push origin master:master'
You could shorten this with 'git push --all'
however, neither of these commands push the Live tag we just added. Without the Live tag, the hook will not run, and the application will not be updated. 
To push tags, you have to add the '--tag' option. This however, will not work with --all, so you have to run these commands seperately:
'git push --tags'
this, however, only push the tag, and if there are changes that are not reflected in that tag, they will not be updated. This will not affect the application, but if you want all portions of your application backed up, you should run the 'git push --all' command as well.
 
Note that when the application is updated or deployed, it is built first by the SAB. If validation fails, the application will not be updated. I do not handle this condition in my scripts. The message is output though, and if the building fails, when the updateApp.bat file is run it will be run on the old files, since no new ones were created, so there should be no harm done. Still, please make sure to validate before you deploy!
 
When you change something about your application and you need to update it, just move the Live tag and push:
First, add changed files:
'git add -A'
Commit changes:
'git commit'
Tag with Live tag. This time, since the Live tag already exists, we have to force the tag with the -f option:
'git tag -f Live'
Push changes to server:
git push --tags'
 
Isn't that simple? Four little commands, on the same machine you are running call studio on, and the application is updated!
Whenever you do a git push --tags after you have updated the Live tag, the application will be updated. If you are simply backing up some changes that are not yet complete, just don't change the live tag, and when you push the application will not be updated. 
 
Since this system include git for version control, rollback tp previous versions is easy.
Assume that in addition to tagging with the Live tag when you deploy, you also tag with a version number, such as v1.0, v1.5, v2.0, etc.
So, you are now working on v2.1. You finish and have debugged the application in call studio, and now it is off hours and you are ready to deploy the changes.
So, you:
'git add -A'
'git commit'
'git tag -f Live'
'git tag v2.1'
'git push --tags'
 
The application updates, you test it, and find an issue. You need to roll back to version 2.0. Simple process now that we have git and this script system:
First, checkout the old version locally:
'git checkout v2.0'
Then, tag it with the Live tag:
'git tag -f Live'
No commit, no changes, we are just checking out an old version.
However, since the server already knows about the Live tag, if we try to push the tag to the server, now that the tag is pointing to an older commit, it will fail.
We can force the server to accept it though. When we do, we need to specify the tag explicitly:
'git push -f origin tag Live' 
That simply tells the git to "Force a push to origin of the tag live"
 
I think that pretty much covers it. I have assumed knowledge of git and gitolite here, so if you want to use this system, you should read up on how to use and install both of those before attempting this.
If you have any questions I'll try to answer.
Comments and suggestions for improvements are welcome!
I do have one improvement already planned; I will be making changes to allow you to use the tag "Dev" to push and deploy changes to a dev environment (as long as it is on the same network of course!)
 
Also, Cisco, if you happen to read this; When you implement the change of ucce to you linux system, I think a system like this would be helpful for application deployment. You seem open to using open-source software in UCCE, so git seems like it would be a welcome addition. ICM scripts have versioning built in, why not Call Studio apps? There are git plugins available for CVP, you could make use of those as well!

Attachments:

1. Yes, you would be creating 8 local repositories. However, if you are concerned about storage, it would be simple to delete the 8 local repositories after the application is updated on the VXML servers. The only purpose of cloning the repos to the VXMl servers is to build and deploy the application.

If a discrepancy somehow occurs on the vxml servers, it would simply be overwritten by the central repo on the next push of the Live tag. Since the VXML servers copy of the repositories are usually going to running in a “detached head” state anyway, there shouldn’t be an issue. The only time an issue could occur is if you accidentally modified the application files on the VXML server, which you shouldn’t be doing. If that did happen, you could simply delete the contents of the appSource folder on the VXML servers, and the next time a push happens, a brand new copy will be cloned instead of updating the old one. Remember, the only purpose of cloning to the VXML server is to build and deploy, so anything inside the appSource folder doesn’t really matter, you can delete it whenever you want. The only reason to keep it is for speed; so that you only have to download the changes.


Talking about “detached head state” reminds me of something I forgot: when you create the local user on the VXML servers that you will use to ssh into them from the git central server, you should place a file called ‘.gitconfig’ inside that user’s Cygwin home directory (C:/Cygwin/home/<username>). The file contents should be:

detachedHead = false
This turns off the warning message on the VXML server’s git install so that when the Live tag is check out it doesn’t display a warning message about being in a detached head state.

2. When you create a new version…
In git, they are called ‘commits’. A commit can be tagged with as many or as few tags as you want. Usually, most commits don’t have tags. Commits are part of ‘branches’ of code.
Tagging with a version tag is the practice most follow when deploying code. The ‘Live’ tag I am using just tells the hooks to run.
To answer the question though, neither.
The whole project is not committed, nor the files that changed, technically.
Only the parts of the file that changed are added to the commit! Which makes git a very efficient system.
As far as merging code goes, git seems to handle it rather well usually, although I’m not sure how well it will do with Call Studio apps, as I have not yet worked on an app at the same time as another person. Unless you are changing the same files though, merging is seamless. If you do change the same files, git will try to merge them, and if it can’t, the conflicting lines will be marked for you to manually change.

I noticed you used the word “Check-in” when talking about pushing to the server. Git does not have ‘check-ins’ like svn and other VCS’ do. In fact, the central repository is not even required. All checkouts of a git repo include the whole repo. Pushing to a server is just a simple way to make sure a project is always available to everyone. And in our case, a place to place the hooks for updating the apps on the VXML server.
If you are interested in git, I would recommended reading the free book ‘Pro Git’: http://git-scm.com/book. If you just want the basics, read chapters 1-3 and the section in chapter 4 on gitolite.

Thanks, let me review this. What are the extra memory requirements it puts on the vxml server ? What happens if tomorrow, we need to patch the vxml server or reinstall the CVP software. Will it affect the git installation or the existing repository in anyway ?
Hemal

That is something important to check, since this is not officially supported by Cisco. However good effort at your end. I will check in this and see what I find.
Hemal