丢失配置君莫怕――手动修复损坏/丢失的Starteam Server配置文件

         昨天服务器被热心的同事冷重启了（其实是处理的东西太多，暂时没反应），结果，今天早上打开Starteam，提示无法连接服务器，于是照例打开“计算机管理”的“服务”，启动Starteam Server（每次重启服务器都需要手动启动服务，尽管该服务已经配置为自动，不知何故，请高手明示），但一个错误对话框告诉我情况并不是像往常那样简单。服务无法启动。

打开Starteam Server的配置程序，以Application模式启动服务，问题依旧，提示配置文件错误（既然能够提示具体的错误，应该好修复，阿门）。

配置文件？嗯，似乎比较熟悉。打开安装Starteam Server安装目录下的starteam-server-configs.xml，yeah！汗下来了…里面空空如也。如果是配置错误，还好搞定，这全都丢了，岂不是让我在一个扣子上缝条裤子？

挥汗之时，突然想到，我的机器上还有一套Server，能不能借花献佛一下呢（？？？谁扔西红柿？乱用个成语也不能这种待遇吧…），死马当活马医，反正也是空了。

以光速的N分之一速度复制来了配置文件，替换，打开，嗯，还是改东西比造东西简单。内容为XML形式，如下所示：

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<StarTeamServerConfigurations version="1.0">

 

 <Configuration name="LogSystem">

    <option name="Initialized" value="1"/>

    <option name="ServerGuid" value="da6070ab-3e11-457a-869a-a563bccc8798"/>

    <option name="CipherName" value=""/>

    <option name="CipherSource" value=""/>

    <option name="CipherTest" value=""/>

    <option name="RepositoryPath" value="F:\StarTeam\LogSystem\"/>

    <option name="LogPath" value="F:\StarTeam\LogSystem\"/>

    <option name="DBType" value="2"/>

    <option name="DBCreated" value="1"/>

    <option name="DBServerName" value="LogSystem"/>

    <option name="DatabaseName" value=""/>

    <option name="DBUserName" value="LogSystem"/>

   <option name="DBPassword" value=""/>

    <option name="ComputerName" value="ERC-ZHM"/>

    <option name="UserName" value="SYSTEM"/>

    <option name="ServiceMode" value="1"/>

    <option name="ListenIP" value=""/>

    <option name="ListenXML" value=""/>

    <option name="MaxCommandThreads" value="0"/>

    <option name="MinCommandThreads" value="0"/>

    <option name="FilesCaching" value="1"/>

    <option name="ChangeRequestsCaching" value="0"/>

    <option name="TopicsCaching" value="0"/>

    <option name="TasksCaching" value="0"/>

    <option name="CompressionOffFileExt" value=""/>

    <option name="CompressionOffFileSize" value="0"/>

    <option name="DeltaStorageOffFileExt" value=""/>

    <option name="DeltaStorageOffFileSize" value="0"/>

    <option name="NotificationLocale" value=""/>

    <option name="BinaryFileExt" value=""/>

    <option name="Sample" value="0"/>

    <option name="CreatedByBuild" value="8.0.172"/>

    <option name="VaultConversionMode" value="-1"/>

    <option name="VerifyOnMD5Collision" value="1"/>

    <option name="PID" value="-1"/>

    <option name="Endpoint" value=""/>

    <option name="Status" value="Ready"/>

 </Configuration>

 

</StarTeamServerConfigurations>

很直观的配置，一个Configuration节就是一个工程，我这里只有一个。该节下面的子节点就是相关的配置内容，凭以前的记忆，我把上面加粗的地方，更改为服务器的本地配置（如果连数据库系统都不一样，那么还需要修改DBType节点，在此的2是MS SQL Server 2000）。保存，启动服务。却被提示“无法匹配数据库标识，GUID不相同”，GUID？。回配置文件里找，果然发现有一个ServerGuid节点，应该是它了。但值没人告诉过我啊，得，再一次傻眼了。

在记忆中搜索了N秒之后，最后还是决定让计算机帮我找。但是，仅凭ServerGuid这个字符串根本找不到任何东西。看来，我只能到我的正常机器上逆向寻找了。所谓逆向寻找，就是在正常机器上根据该节点的值来搜索它存在的位置。在文件中搜索，只有starteam-server-configs.xml文件存在该值（废话，没有就怪了），其它地方都没有，我连蜂巢（版本库所在目录）都找了，同样无果。

难道，就眼睁睁看着多少天的心血毁在一个GUID上？镇定之后，我把所有希望都放在了版本库基本数据――数据库上，从根下找！。使用MS SQL的企业管理器打开MS SQL的Starteam实例，找到以工程名称命名的数据库，挨着表寻找。哎呀，功夫不负有时间的人啊，最后我在S0这个表的F3列找到了这个值。回到服务器上，复制、粘贴、启动，成功！我太有才了。

不过最后还有个小问题，被修复的Starteam Server以Windows服务运行时还会报错，只需把该服务删除，重新注册一下就OK了。

至此，服务器修复成功。

结语：

1、 版本管理工具也需要备份维护，养成定时备份的习惯有百利而无一害。

2、 在程序出现问题时，要看清它的错误提示，以达到有的放矢

3、 在原数据丢失的情况下，可以使用另一个正常系统来辅助确定数据存在的位置

4、 在写程序的时候，尽量把异常细化，让用户摸得着头脑。