Moving Sharepoint (MOSS) from One Server to Another

Moving Sharepoint (MOSS) from One Server to Another

Lots of information exists on the internet concerning how to backup, restore, and move Microsoft Office Sharepoint Server (MOSS). Here, I will refer to this simply as "Sharepoint". Many developers (including myself) have wondered, "what is the easiest way to fully backup and restore, and even in the process, move, Sharepoint?"...so here an easy way to do a full backup of one Sharepoint server, then restore to another Sharepoint server...

Sharepoint backup from original (source) server:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o backup -url http://mysourceserver:80/ -filename C:\sharepoint_backups\myoriginalsharepointinstance.bak

Sharepoint restore to another (destination) server:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o restore -url http://mydestinationserver/ -overwrite -filename C:\sharepoint_backups\myoriginalsharepointinstance.bak


Using Ant to Automate Version Control Operations and Software Metrics

Using Ant to Automate Version Control Operations and Software Metrics

Like many developers, I use Ant to build and deploy software. Through the years, I have grown an inordinate fondness for Ant, and I have enjoyed finding ways to automate all sorts of processes in the software development life cycle.

Here, I would like to show some examples of using Ant to interact with a version control system, and to also collect software metrics.

For version control, many of us use Subversion to maintain our software repositories, and essentially, manage our intellectual property. One of the challenges in concurrently developing a system, on a team, is keeping in sync with the latest (or some particular) revision of the software. Ant can help in this endeavour.

Here, I show how Ant can be used to do an svn update on the local copy of code. I use this Ant target to ensure that I have the latest updates to the code I am working with; this target acts as a kind of continuous integration tool on Agile projects. So, introducing the Ant svnupdate target...

In the build.properties, add

# SVN Client Home -- where svn client can be found.
# eg: svnclient.home=C:/cygwin/bin/svn.exe
# or
# svnclient.home=/usr/bin/svn

Then, in the build.xml, include

<!-- Svnupdate Target -->
<target name="svnupdate" description="Updates code source to HEAD.">
<exec executable="${svnclient.home}">
<arg line='"update"'/>

To do an svn update on your local copy, then simply use the svnupdate target, like this:

ant svnupdate

I typically combine it with the whole build, so that it is called just before the other targets.

Also, you can use Ant to create a README file based on information in the repository. To do this, add this target to the build.xml file:

<!-- Svninfo Target -->
<target name="svninfo"
description="Gets Subversion data about this local copy.">
<exec executable="${svnclient.home}" output="README">
<arg line='"info"'/>

This would be run as:

ant svninfo

It outputs a README file that can also, using Ant, be inserted into the final deployment (eg: a WAR file or JAR file).

Ant can also call software that performs metrics. One such software, StatSVN, does an excellent job of generating statistics and charts representing the metrics of a build. Here is an example of using Ant to call StatSVN...

In build.properties:

# StatSVN parameters.
# See http://www.statsvn.org/

In build.xml:

<!-- Statsvn Target -->
<target name="statsvn" description="Runs statsvn.jar on the local copy.">
<mkdir dir="${statsvn.outputdir}"/>
<exec executable="${svnclient.home}" output="${svn.log}">
<arg line='"log"'/>
<arg line='"--xml"'/>
<arg line='"-v"'/>
<java jar="${lib.statsvn}" fork="true" failonerror="true" classpath=".;${lib.statsvn}">
<arg line="${svn.log}"/>
<arg line="."/>
<arg line="-output-dir"/>
<arg line="${statsvn.outputdir}"/>

This would be run as:

ant statsvn