一个人不应该依附在其他人身上,一个人应该首先自力更生。你应该自己能够独立,能够安顿你自己,那你就不会害怕了。你爱你自己的话,别人不能不爱你吧。

发布新日志

  • Subversion库迁移及备份方案

    2009-11-11 17:10:37

    Subversion库迁移及备份方案

    在做迁移操作前,请停止对svn进行提交操作。
    1. 迁移方案(采用dump -load方案):

    源SVN服务器:192.168.1.200,Windows服务器

    目标SVN服务器:192.168.1.201,Windows服务器。采用CollabNet Subversion Server,假定subversion安装在D:\Program Files\CollabNet Subversion Server上,SVN的Repository为d:\Subversion\svnbackup

    也即Windows服务中,可执行文件的路径为:

    “d:\Program Files\CollabNet Subversion Server\svnserve.exe” –service -r “d:\Subversion\svnbackup” –listen-port “3690″

    由于目前在subversion服务器上实际上只有svn://192.168.1.200/rd目录下才有内容,因此只需要迁移svn://192.168.1.201/rd下的内容,步骤如下:

    1、 在源服务器192.168.1.200上执行dump操作

    注意此处实际上把repository中所有的目录都备份了,需要在load时候采用svndumpfilter命令过滤需要的目录。

    svnadmin dump D:\Subversion\svnworkspace\bak >svn_all_20080520.dump

    2、 在192.168.1.201上创建svnbackup Repository

    svnadmin create d:\Subversion\svnbackup

    3、 下载一个windows 版本gnu 工具(例如http://sourceforge.net/projects/gnuwin32/),主要是使用cat方法

    4、 将dump文件拷贝到上并执行load操作

            cat svn_all_20080520.dump | svndumpfilter --include:rd >svn_rd_20080520.dump

    5、 执行svnadmin load

            svnadmin load d:\Subversion\svnbackup < svn_rd_20080520.dump

    6、 在192.168.1.201上配置svnserve.conf、passwd、authz文件
    2. 迁移方案(采用svnsync方案)

    从subversion 1.4.4开始,提供了svnsync命令,可用于Subversion的库迁移和备份,这里我们用于备份操作的初始化同步。

    假定从源服务器192.168.1.201备份到192.168.1.88

    SVN服务器:192.168.1.201,Windows服务器,采用CollabNet Subversion Server,假定subversion安装在D:\Program Files\CollabNet Subversion Server上,SVN的Repository为d:\Subversion\svnbackup。

    备份服务器: 192.168.1.88,Redhat As 4服务器

    采用svnsync进行数据迁移,方法如下:

    1、 在备份服务器192.168.1.88上创建源服务器192.168.1.201上对应的备份库目录

    mkdir /opt/subversion

    svnadmin create  /opt/subversion/svnbackup

    2、在备份服务器192.168.1.88上启用钩子文件

    cd  /opt/subversion/svnbackup/hooks

    echo “#!/bin/sh”> pre-revprop-change

    chmod 755 pre-revprop-change

    3、在备份服务器192.168.1.88上运行svnsync init命令

    svnsync init file:////opt/subversion/svnbackup  svn://192.168.1.201 –username username –password password

    注意,svnsync的语法为:svnsync init DEST SOURCE

    4、在备份服务器192.168.1.88上执行同步操作

    svnsync sync file:////opt/subversion/svnbackup

    由于svnsyc只能同步整个svn库,并不能同步指定的项目,因此建议迁移时候使用dump-load方案,备份时候采用svnsync方案
    3. 备份方案:

    为保证svn服务器的安全,由脚本每天定时对svn库进行备份,以保证svn库的安全性。备份仍然采用svnsync来完成。

    1. 在192.168.1.88  上安装subversion 服务器端

    2. 在192.168.1.88上创建备份用户帐号svnsync,以供192.168.1.201能够以此帐号实时把变更的同步到192.168.1.88上

    配置文件svnserve.conf:

    [general]

    anon-access = none

    auth-access = write

    password-db = passwd

    authz-db = authz

    配置文件passwd:

    svnsync=svnsync

    配置文件authz

    [groups]

    developer = svnsync

    [/]

    @developer=rw

    * =

    3. 在备份机上开启iptables的3690端口

    4. 在备份机192.168.1.88上创建备份库目录

    svnadmin create /opt/subversion/svnbackup

    chown –R svnsync:svnsync  /opt/subversion/svnbackup

    5. 按照上述采用svnsync方案的步骤,将库同步到192.168.1.88上,初始化svn库

    cd  /opt/subversion/svnbackup/hooks

    echo “#!/bin/sh”> pre-revprop-change

    chmod 755 pre-revprop-change

    svnsync init file:////opt/subversion/svnbackup  svn://192.168.1.201 –username username –password password

    svnsync sync file:////opt/subversion/svnbackup

    6. 在源服务器192.168.1.201上,创建钩子文件,保证192.168.1.201上的变动实时同步到192.168.1.88上:
    post-commit

    # Propagate the data to the remote repository

    D:\Program Files\CollabNet Subversion Server\svnsync synchronize --username svnsync --password svnsync  svn:// 192.168.1.88

    post-rev-changes

    # Propagating changes to the remote repository.

    D:\Program Files\CollabNet Subversion Server\bin\svnsync copy-revprops --username svnsync --password svnsync  svn:// 192.168.1.88 $REV 

    4. 参考文档:

    http://blog.notreally.org/articles/2006/11/30/setting-up-a-subversion-mirror-repository-using-svnsync/

  • 详说Subversion备份

    2009-11-11 16:48:02

    作者: rocksun   
    2006-10-26

    作者:Rock Sun, Subversion中文站。
    如有转发请注明出处:http://www.subversion.org.cn/ind ... ;id=85&Itemid=9

    版本控制最关键的一件事是保证数据的安全性,不能因为磁盘损坏,程序故障造成版本库无可挽回的错误,为此必须制定较完备的备份策略。在Subversion中,我们有三种备份方式:完全备份,增量备份和同步版本库。
    1, 完全备份

    最常见和简单的备份就是直接使用拷贝命令,将版本库目录拷贝到备份目录上,就可以了。但是这样不是很安全的方式,因为如果在拷贝时版本库发生变化,将会造成备份的结果不够准确,失去备份的作用,为此Subversion提供了“svnadmin hotcopy”命令,可以防止这种问题。

    还记得我们的版本库目录吗?

        D:\SVNROOT
        ├─project1
        │  ├─conf
        │  ├─dav
        │  ├─db
        │  │  ├─revprops
        │  │  ├─revs
        │  │  └─transactions
        │  ├─hooks
        │  └─locks
        └─project2
            ├─conf
            ├─dav
            ├─db
            │  ├─revprops
            │  ├─revs
            │  └─transactions
            ├─hooks
            └─locks
          

    我们在D:\SVNROOT下创建了两个文件,simpleBackup.bat:

        @echo 正在备份版本库%1......
        @%SVN_HOME%\bin\svnadmin hotcopy %1 %BACKUP_DIRECTORY%\%2
        @echo 版本库%1成功备份到了%2!

    这个文件仅仅是对“svnadmin hotcopy”的包装,然后是backup.bat:

        echo off

        rem Subversion的安装目录
        set SVN_HOME="D:\Subversion"

        rem 所有版本库的父目录
        set SVN_ROOT=D:\svnroot

        rem 备份的目录
        set BACKUP_SVN_ROOT=D:\svnrootbak

        set BACKUP_DIRECTORY=%BACKUP_SVN_ROOT%\%date:~0,10%
        if exist %BACKUP_DIRECTORY% goto checkBack
        echo 建立备份目录%BACKUP_DIRECTORY%>>%SVN_ROOT%/backup.log

        mkdir %BACKUP_DIRECTORY%
        for /r %SVN_ROOT% %%I in (.) do @if exist "%%I\conf\svnserve.conf" %SVN_ROOT%\simpleBackup.bat "%%~fI" %%~nI
        goto end

        :checkBack
        echo 备份目录%BACKUP_DIRECTORY%已经存在,请清空。
        goto end

        :end

    根据以上的配置,你只需要运行backup.bat,就可以把“SVN_ROOT”下的版本库都备份到“BACKUP_SVN_ROOT”里,并且存放在备份所在日的目录里,例如“D:\svnrootbak\2006-10-22”。

    虽然这部分工作很简单,可是必须有人定时地去执行这个操作(例如每周五),为了避免发生遗忘的情况,我们可以将这个操作加入到系统的at人物当中去,例如还是上面的环境,为了安装at,我们运行:

        at 1:00 /every:M D:\svnroot\backup.bat

    这样在每周一凌晨1:00都会执行这个备份过程。当然备份在本机也是不安全的,你也许需要上传到别的机器,这个就要靠你自己去实现了。

    2, 增量备份

    尽管完全备份非常简单,但是也是有代价的,当版本库非常巨大时,经常进行完全备份是不现实的,也并不必要,但是一旦版本库在备份之间发生问题,该如何呢,这里我们就用到了增量备份。

    增量备份通常要与完全备份结合使用,就像oracle数据库的归档日志,记录着每次Subversion提交的变化,然后在需要恢复时能够回到最新的可用状态。

    为了记录每次提交的结果,我们需要使用一项Subversion的特性--钩子(hook),看看我们的project1目录:

        ├─project1
        │  ├─conf
        │  ├─dav
        │  ├─db
        │  │  ├─revprops
        │  │  ├─revs
        │  │  └─transactions
        │  ├─hooks
        │  └─locks

    其中的hooks目录里存放的就是钩子脚本,我们在此处只使用post-commit钩子,这个钩子会在每次提交之后执行,为了实现我们的备份功能,我们在hooks下建立一个文件post-commit.bat,内容如下:

        echo off
        set SVN_HOME="C:\Program Files\Subversion"
        set SVN_ROOT=D:\svnroot
        set UNIX_SVN_ROOT=D:/svnroot
        set DELTA_BACKUP_SVN_ROOT=D:\svnrootbak\delta
        set LOG_FILE=%1\backup.log
        echo backup revision %2 >> %LOG_FILE%
        for /r %SVN_ROOT% %%I in (.) do if D:/svnroot/%%~nI == %1 %SVN_ROOT%\%%~nI\hooks\deltaBackup.bat %%~nI %2
        goto end
        :end

    通过这个脚本,可以实现D:\svnroot下的版本库提交时自动增量备份到D:\svnrootbak\delta(确定这个目录存在),其中使用的deltaBackup.bat其实可以放在任何地方,只是对脚本的svnadmin dump的包装,内容如下:

        @echo 正在备份版本库%2......
        %SVN_HOME%\bin\svnadmin dump %SVN_ROOT%\%1 --incremental --revision %2 >> %DELTA_BACKUP_SVN_ROOT%\%1.dump
        @echo 版本库%2成功备份到了%3!

    以上两个脚本可以直接拷贝到project2的hooks目录下,不需要修改就可以实现project2的自动备份。

    以上的操作已经OK了,现在需要做的是将完全备份和增量备份结合起来,也就是在完全备份后清理增量备份的结果,使只保存完全备份后的结果。

    最后的结果,可以下载附件,将之解压缩到d:\下,然后修改几个bat文件的SVN_HOME就可以使用了。
    3, 版本库同步

    Subversion 1.4增加了同步机制,可以实现一个版本库同另一个版本库的同步(但好像只是单向的),我们可以用来实现版本库的备份或镜像。
    3.1. 对目标库初始化

        svnsync init svn://localhost/project2 svn://localhost/project1
         

    其中project2是目标的版本库,而project1是源版本库。其中的目标版本库必须为空,而且必须训育修订版本属性的修改,也就是在目标的版本库的hooks目录里添加一个文件pre-revprop-change.bat,内容为空即可。
    3.2. 同步project2到project1

        svnsync sync svn://localhost/project2
         

    这时候你update一下你的project2的一个工作拷贝,就会发现有了project1的所有内容。如果project1又有提交,这时候 project2的版本库无法看到最新的变化,还需要再运行一遍sync操作,这样才能将最新的变化同步。需要注意的是,目标版本库只能做成只读的,如果目标版本库发生了变更,则无法继续同步了。
    3.3. 同步历史属性的修改

    因为同步不会更新对历史属性的修改,所以svnsync还有子命令copy-revprops,可以同步某个版本的属性。
    3.4. 钩子自动同步

    希望在每次提交时同步,则需要在源版本库增加post-commit脚本,内容如下:

    echo off
    set SVN_HOME="D:\Subversion"
    %SVN_HOME%\bin\svnsync sync  --non-interactive svn://localhost/project2


    把以上内容存放为post-commit.bat,然后放到版本库project1下的hooks目录下,这样project1每次提交,都会引起project12的同步。

  • SVN Backup Widget

    2009-11-11 16:17:01

    Project Description
    Utility to create Subversion repository backups using the svnadmin dump command. This utility allows you to create profiles for different backup scenarios.

    Support Forums
    http://www.systemwidgets.com/Support/Forums/tabid/72/view/topics/forumid/2/Default.aspx

    Screen Shots

    Opening Screen
    initial screen.gif

    Configuration Screen
    server settings.gif

    Successful Setup
    successful server setup.gif
    Last edited Mar 11 at 11:47 PM by HectorSosaJr, version 11
  • svn目录结构组成的教程

    2009-09-29 17:20:07

    wolfwebadmin
    ├─ProjectManagement
    │  ├─trunk
    │  ├─branches
    │  └─tags
    └─SSO
        ├─trunk
        ├─branches
        └─tags
    大概的说一下, ProjectManagement和SSO是两个项目 trunk是开发的主线代码, 存放能够运行的正确的代码; 程序员如果开发新的程序或者改bug, 一般要先branch(SVN的一个功能) trunk目录下的代码到branches目录的一个子目录,在那里对代码进行修改, 确认无误后再提交到trunk主线下(但是有的时候为了效率, 我们也多人都在trunk目录下开发项目). tags目录可以看做主线代码的快照, 比如你做了1.0又做了2.0, 那每个不同版本的代码你就做快照放到tags文件夹下了.

     
    一下文字转自http://rocksun.cn/svn/?p=43 Subversion版本库布局 很多人问我”什么是推荐的版本库布局?”,”trunk是什么意思?”或”trunk有什么意义?”,本文将会尝试回答这个问题。

    一个Subversion版本库实现了一种版本化的文件系统,版本库只是一个包含目录和文件的文件系统,而且它的文件系统是版本化的,并且实现了” 廉价”拷贝,让它的这种操作比传统文件系统便宜很多,但是版本库本身还是像一个文件系统:Subversion本身没有特别的目录或名称用来代表 trunk或branches,他们只是文件系统的普通目录,这依赖于你给这些目录名和结构的一种意义。

    也就是说,社区已经采纳了多种普通的布局作为最佳实践,因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的,根据这些习惯,用户可以方便的访问版本库来查找他们所需要的。

    有两种常见的布局:

    trunk
    branches
    tags
    第一种布局是版本库包含一个项目或一组紧密联系项目的最佳选择,这个布局非常好用,因为分支与标签整个项目或一组项目会非常简单,只需要一个简单的命令:

    svn copy url://repos/trunk url://repos/tags/tagname -m “Create tagname”

    这可能是最常用的版本库布局,被许多开源项目采用,就像Subversion本身和Subclipse,这是大多数主机站点,如Tigris.org, SourceForge.net和Google Code遵循的方法,这些站点的每个项目有自己的版本库。

    另一种布局是针对一个版本库包含不相关项目的最佳选择。

    ProjectA
       trunk
       branches
       tags
    ProjectB
       trunk
       branches
       tags
    在这种布局里,每个项目会存在顶级目录里,然后该目录之下创建trunk/branches/tags,其中与第一种布局相同,这只是将项目放到自己版本库方式的替换,他们都在一个版本库中。Apache软件基金会使用这种布局方式来存放他们的所有项目在一个版本库。

    通过这种布局,每个项目都有自己的分支和标签,可以很容易使用一个命令创建分支和标签,就像前面展示的:

    svn copy url://repos/ProjectA/trunk url://repos/ProjectA/tags/tagname -m “Create tagname”

    这种布局可以简单的创建同时包含ProjectA和ProjectB的标签,你可以这样做,但是需要多个命令,你也要决定是否创建一个特别的目录存放这种分支和标签,如果你需要经常这样做,你或许应该考虑第一种布局。

    至于版本库中目录的名称,再说一遍:只是一种习惯,他们在Subversion中没有特别含义。

    “trunk”可以认为是项目的开发主线,你可以称之为 “main”,”mainline”,”production”或任何你喜欢的名字。

    “branches”是放置分支的地方,人们因各种目的使用分支,你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等,在这个例子里,你可以在branches创建一层目录,或只是在顶级目录创建多个分支目录。

    “tags”也不会被Subversion特别对待,他们只是习惯,或许通过钩子脚本或授权规则进行强制,来指明你创建了一个时间点的快照,通常情况下tags与分支的区别就是tags一旦创建不能修改,你也可以将标签目录叫做”releases” ,”snapshots”,”baselines”或任何你喜欢的。

    记住,名称对你有意义,不是Subversion。最后,Subversion的架构,全局修订版本经常使得标签没有必要,我不知道只是因为要创建 tag而创建tag有什么意义,如果你需要在特定时间点重建软件,你可以通过svn log来确定相关的修订版本号。tags对于版本库的”外部”用户很有用,或许QA/Release团队需要执行构建,或许是一个内部开发小组希望在另一个产品使用发布版本,或是外部用户或客户希望根据字面含义从版本库获取发布快照,在这些场景中,创建tag是保证获取正确代码的最简单方法,也需要有好的交流机制来指明发布快照。

    希望本文可以为你澄清一些问题,让你更好的理解Subversion是如何工作的。

    最后,我希望指出Subversion版本库的布局是可以修改的,你可以一直重组和重构布局,最坏情况下,会让用户调整他们的工作拷贝,但不会让你从头再来,你应该自由的改名,移动目录或任何你希望改变版本库的方式去做。

    文章来自[SVN中文技术网]转发请保留本站地址:http://www.svn8.com/SVNzixun/20080414/502.html

Open Toolbar