通过脚本设置外部时,Subversion存储库已损坏

时间:2014-02-17 03:37:37

标签: svn version-control ksh corrupt svn-externals

我有一个自动脚本(用KSH编写),用于为存储库中的文件夹设置SVN外部。当我运行此脚本时,它执行以下操作:

完全检查存储库的一部分。

然后,循环遍历具有所有Subversion属性的文件以设置外部和:

  1. 执行本地工作副本的SVN更新。输出 脚本当前文件夹的当前SVN外部属性 继续努力。 (可以是一个或多个级别深)
  2. 从文件中提取新外部的变量
  3. 使用svn在此文件夹中设置以前的外部和一个新的外部 propset命令。
  4. 将更改提交到存储库
  5. 然后脚本移动到文件的下一行。

    脚本摘录:

    mkdir "${SVNLOC}/${PROJNAME}"
    svn co --no-auth-cache --username $SVNUSER --password $SVNPASSWORD "${1}" "${SVNLOC}/${PROJNAME}" >> $LOGFILE 2>&1
    
    while read extline
    do
    
    # parse line for variables
    parent=$(echo $extline | cut -f1 -d,);
    extfolder=$(echo $extline | cut -f2 -d,);
    exturl=$(echo $extline | cut -f3 -d,);
    revision=$(echo $extline | cut -f4 -d,);
    
    # execute a SVN update to ensure we have the very latest properties
    echo "SVN Update in ${SVNLOC}/${PROJNAME}" >> $LOGFILE 2>&1
    echo "svn update --no-auth-cache --username $SVNUSER --password $SVNPASSWORD --ignore-externals ${SVNLOC}/${PROJNAME}/${parent}" >> $LOGFILE 2>&1
    svn update --no-auth-cache --username $SVNUSER --password $SVNPASSWORD --ignore-externals ${SVNLOC}/${PROJNAME} >> $LOGFILE 2>&1
    
    # change directory to folder in local check-out where external will be set.
    cd ${SVNLOC}/${PROJNAME}/${parent}
    pwd >> $LOGFILE 2>&1
    
    # if the revision is empty/unset then set external with out revision setting
    if [ "$revision" == "" ] ; then
    
    echo "Set External ${exturl} at ${SVNLOC}/${PROJNAME}/${parent}" >> $LOGFILE 2>&1
    # output externals info to a file
    echo "'${extfolder}' '${exturl}'" > svnext
    # append current externals to the list so they're not deleted
    svn propget --no-auth-cache --username $SVNUSER --password $SVNPASSWORD svn:externals . >> svnext
    # set new and existing externals to the property
    svn propset --no-auth-cache --username $SVNUSER --password $SVNPASSWORD svn:externals --file svnext . >> $LOGFILE 2>&1
    rm svnext
    else    # if the revision is set then set external with revision setting
    
    echo "Set External ${exturl}@${revision} at ${SVNLOC}/${PROJNAME}/${parent}" >> $LOGFILE 2>&1
    
    # output externals info to a file
    echo "'${extfolder}' -r${revision} '${exturl}'" > svnext
    # append current externals to the list so they're not deleted
    svn propget --no-auth-cache --username $SVNUSER --password $SVNPASSWORD svn:externals . >> svnext
    # set new and existing externals to the property
    svn propset --no-auth-cache --username $SVNUSER --password $SVNPASSWORD svn:externals --file svnext . >> $LOGFILE 2>&1
    rm svnext
    
    fi
    
    # commit externals set in this loop
    echo "Commit Externals in ${SVNLOC}/${PROJNAME}/${parent}" >> $LOGFILE 2>&1
    echo "svn commit --no-auth-cache --username $SVNUSER --password $SVNPASSWORD -m "Committing externals to SVN for Project ${PROJNAME}" ${SVNLOC}/${PROJNAME}" >> $LOGFILE 2>&1
    svn commit --no-auth-cache --username $SVNUSER --password $SVNPASSWORD -m "Committing externals to SVN for Project ${PROJNAME}" "${SVNLOC}/${PROJNAME}" >> $LOGFILE 2>&1
    
    done < "$2"
    

    SVN提交可能在循环的前几次迭代中起作用,但是在具有SVN错误的迭代中失败,例如:

    svn: E160004: Commit failed (details follow):
    svn: E160004: Corrupt node-revision '0.0.r180/4191'
    

    但是,如果我对存储库执行svnadmin验证,我的脚本正在处理它,表示修订已经过验证:

    * Verified revision 177.
    * Verified revision 178.
    * Verified revision 179.
    * Verified revision 180.
    

    因此,如果我在错误之后对存储库(或使用TortoiseSVN查看)工作,我会得到上面相同的svn错误,但它没有被svnadmin验证。

    编辑:我确实检查了所涉及的SVN服务器上的SVN错误日志,发现以下错误:

    Could not MERGE resource "<SVN_REPOS_PATH>/!svn/txn/179-4z" into "<SVN_REPOS_PATH>/<PATH_TO_FOLDER>".  [500, #0]
    Could not open the FS root for the revision just committed.  [500, #160004]
    Corrupt node-revision '0.0.r180/4191'  [500, #160004]
    Missing id field in node-rev  [500, #160004]
    Could not fetch resource information.  [404, #0]
    (2)No such file or directory: Named transaction doesn't exist.  [404, #0]
    

    仍未解释为什么提交确实失败。

    有没有人遇到过这个?如果有任何提示,建议或可能的解决方案?

    我正在使用SVN 1.7.2 CLI客户端对1.7.8 SVN存储库。

0 个答案:

没有答案