丢失配置君莫怕――手动修复损坏/丢失的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、 在写程序的时候,尽量把异常细化,让用户摸得着头脑。
标签:
文章分类 FK Coding

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

点赞
如果您觉得很赞,我将非常乐意接受虚拟币的捐赠,以示您对我的肯定。

比特币钱包地址:
1PqpqA8FyH3NbfCrbcRd1YxQk3LEsSEYDV
莱特币钱包地址:
LRTdmovGGVEHCKWz7JdL9aiB7VZkuNycJf
站点勋章
网站统计