使用google自定义搜索引擎

mailman,google自定义搜索引擎,搜索站点,邮件列表

google搜索引擎很强大,如果没有机密信息的话,是否可以尝试让google来帮我们完成全站搜索引擎,而不必再自己去建立。

下文是个例子,用google自定义搜索引擎来搜索指定的邮件列表,具体步骤如下:

 

1)下载并安装sitemap生成器
参考:http://code.google.com/p/perlsitemapgenerator/

2)(可能需要)安装XML:SAX

$ perl -MCPAN -e shell
cpan> install XML::LibXML XML::SAX::Base XML::SAX::ExpatXS XML::SAX::Writer
cpan> quit

参考:http://www.ibm.com/developerworks/cn/xml/x-xmlperl2.html#resources

3)按要求修改comfig.xml ,另存为testlist_config.xml

   内容如下:

[root@retailsolution sitemap_gen_perl]# vi testlist_config.xml
 
<?xml version="1.0" encoding="UTF-8"?>
<!--
  sitemap_gen.pl example configuration script
 
  This file specifies a set of sample input parameters for the
  sitemap_gen.pl client.
 
  You should copy this file into "config.xml" and modify it for
  your server.
 
 
  ********************************************************* -->
 
 
<!-- ** MODIFY **
  The "site" node describes your basic web site.
 
  Required attributes:
    base_url   - the top-level URL of the site being mapped
    store_into - the webserver path to the desired output file.
                 This should end in '.xml' or '.xml.gz'
                 (the script will create this file)
 
  Optional attributes:
    verbose    - an integer from 0 (quiet) to 3 (noisy) for
                 how much diagnostic output the script gives
    suppress_search_engine_notify="1"
               - disables notifying search engines about the new map
                 (same as the "testing" command-line argument.)
    default_encoding
               - names a character encoding to use for URLs and
                 file paths.  (Example: "UTF-8")
-->
<site base_url="http://report.retailsolution.cn/mhonarchive/testlist/" store_into="/var/lib/mhonarc/archives/testlist/sitemap.xml" verbose="1">
 
  <!-- ********************************************************
          INPUTS
 
  All the various nodes in this section control where the script
  looks to find URLs.
 
  MODIFY or DELETE these entries as appropriate for your server.
  ********************************************************* -->
 
  <!-- ** MODIFY or DELETE **
    "url" nodes specify individual URLs to include in the map.
 
    Required attributes:
      href       - the URL
 
    Optional attributes:
      lastmod    - timestamp of last modification (ISO8601 format)
      changefreq - how often content at this URL is usually updated
      priority   - value 0.0 to 1.0 of relative importance in your site
  -->
 
 
 
  <!-- ** MODIFY or DELETE **
    "urllist" nodes name text files with lists of URLs.
    An example file "example_urllist.txt" is provided.
 
    Required attributes:
      path       - path to the file
 
    Optional attributes:
      encoding   - encoding of the file if not US-ASCII
  -->
 
 
 
  <!-- ** MODIFY or DELETE **
    "directory" nodes tell the script to walk the file system
    and include all files and directories in the Sitemap.
 
    Required attributes:
      path       - path to begin walking from
      url        - URL equivalent of that path
 
    Optional attributes:
      default_file - name of the index or default file for directory URLs
  -->
  <directory path="/var/lib/mhonarc/archives/testlist/" url="http://report.retailsolution.cn/mhonarchive/testlist/" />
 
 
 
  <!-- ** MODIFY or DELETE **
    "accesslog" nodes tell the script to scan webserver log files to
    extract URLs on your site.  Both Common Logfile Format (Apache's default
    logfile) and Extended Logfile Format (IIS's default logfile) can be read.
 
    Required attributes:
      path       - path to the file
 
    Optional attributes:
      encoding   - encoding of the file if not US-ASCII
  -->
 
 
  <!-- ** MODIFY or DELETE **
    "sitemap" nodes tell the script to scan other Sitemap files.  This can
    be useful to aggregate the results of multiple runs of this script into
    a single Sitemap.
 
    Required attributes:
      path       - path to the file
  -->
 
 
  <!-- ********************************************************
          FILTERS
 
  Filters specify wild-card patterns that the script compares
  against all URLs it finds.  Filters can be used to exclude
  certain URLs from your Sitemap, for instance if you have
  hidden content that you hope the search engines don't find.
 
  Filters can be either type="wildcard", which means standard
  path wildcards (* and ?) are used to compare against URLs,
  or type="regexp", which means regular expressions are used
  to compare.
 
  Filters are applied in the order specified in this file.
 
  An action="drop" filter causes exclusion of matching URLs.
  An action="pass" filter causes inclusion of matching URLs,
  shortcutting any other later filters that might also match.
  If no filter at all matches a URL, the URL will be included.
  Together you can build up fairly complex rules.
 
  The default action is "drop".
  The default type is "wildcard".
 
  You can MODIFY or DELETE these entries as appropriate for
  your site.  However, unlike above, the example entries in
  this section are not contrived and may be useful to you as
  they are.
  ********************************************************* -->
 
  <!-- Exclude URLs that end with a '~'   (IE: emacs backup files)      -->
  <filter action="drop" type="wildcard" pattern="*~" />
 
  <!-- Exclude URLs that is a picture gz bak file       -->
  <filter action="drop" type="wildcard" pattern="*jpg" />
  <filter action="drop" type="wildcard" pattern="*gif" />
  <filter action="drop" type="wildcard" pattern="*bmp" />
  <filter action="drop" type="wildcard" pattern="*gz" />
  <filter action="drop" type="wildcard" pattern="*bak" />
 
  <!-- Exclude URLs within UNIX-style hidden files or directories       -->
  <filter action="drop" type="regexp" pattern="/\.[^/]*" />
 
</site>

 

参考:http://code.google.com/p/perlsitemapgenerator/wiki/Create

4)测试

   perl sitemap_gen.pl –config=testlist_config.xml –testing

   参考:README

   没问题,一切OK

4) 运行

   perl sitemap_gen.pl –config=testlist_config.xml

   没问题,一切OK, 成功生成sitemap.xml 并且通知了google的搜索引擎。

5)用gmail帐号登录 google, 使用向导创建一个自定义搜索引擎

6) 自定义搜索引擎后,在我的帐户->网站管理员工具->选择一条你创建自定义搜索引擎时使用的网站地址

   ->SiteMaps

   在我的 SiteMaps处输入 sitemap.xml

   然后点击【提交SiteMap】  
7) 在我的帐户->我的搜索引擎->针对刚才创建的搜索引擎->控制面板->编制索引

   在 按需编入索引 下选择刚才提交的 sitemap.xml,然后【Index Now】

   完成后,google提示成功刷新了索引。

8) 在我的帐户->我的搜索引擎->针对刚才创建的搜索引擎->控制面板->预览  中

   输入一个你的邮件列表中的关键词,执行搜索,结果没有搜到。别灰心,你需要等待大约2个小时。

   2小时以后再执行搜索,发现已经能够搜索到指定的关键词了。

   到这里,自定义搜索引擎创建,测试成功。

9)在我的帐户->我的搜索引擎->针对刚才创建的搜索引擎->控制面板->代码

   把 搜索框代码 下面的代码copy到要显示搜索框的网页中,比如邮件类表的索引页:threads.html中

   现在当我们访问邮件列表归档的时候,就可以看到搜索框了:

http://report.retailsolution.cn/mhonarchive/testlist/threads.html

   试着这行一个搜索,确实是我们期望的结果。

10)使用 cron job 周期执行  perl sitemap_gen.pl –config=testlist_config.xml

    可参考:http://www.linuxsir.org/main/?q=node/209

11)我们还可以创建另一个自定义搜索引擎,把我们要搜索的内容全部整合到一起。

    11.1) 建立一个脚本文件,为其他maillist创建sitemap:gen_maillist_sitemap.sh 内容如下:

sitemap_gen_path=/d01/sitemap_gen_perl 
export sitemap_gen_path 
perl $sitemap_gen_path/sitemap_gen.pl --config=$sitemap_gen_path/testlist_config.xml 
perl $sitemap_gen_path/sitemap_gen.pl --config=$sitemap_gen_path/channelproject-commits_config.xml 
perl $sitemap_gen_path/sitemap_gen.pl --config=$sitemap_gen_path/datafix_config.xml 
perl $sitemap_gen_path/sitemap_gen.pl --config=$sitemap_gen_path/handtech_config.xml 
perl $sitemap_gen_path/sitemap_gen.pl --config=$sitemap_gen_path/report-maillist_config.xml

 
    chmod 744 gen_maillist_sitemap.sh

    11.2)把这个脚本放到crontab 每天定时运行

    cd /etc

    cp crontab crontab.bak

    vi crontab ,  添加:

    02 4 * * * root /d01/sitemap_gen_perl/gen_maillist_sitemap.sh

    #每天 4时2分运行这个脚本

    #重启crond 服务

    service crond restart

    11.3) 建立一个自定义搜索引擎,把上述sitemap都包括进去。同时把属于retailsolution.cn域上的其他站点的sitemap也包括进去。

    这样可以形成一个对retailsolution.cn全域的搜索引擎

比如这个搜索引擎就可以搜索retaisolution.cn上的 report.retailsolution.cn,blog.retailsolution.cn,all maillist 
   

<!-- Google Customer serch engine begin -->
<form id="cse-search-box" action="http://www.google.com/cse">
  <div>
    <input type="hidden" value="016037023302352540634:y7c8yn6q_ra" name="cx" />
    <input type="hidden" value="UTF-8" name="ie" />
    <input style="border-right: #7e9db9 1px solid; padding-right: 2px; border-top: #7e9db9 1px solid; padding-left: 2px; background: url(http://www.google.com/coop/intl/zh-Hans/images/google_custom_search_watermark.gif) #ffffff no-repeat left 50%; padding-bottom: 2px; border-left: #7e9db9 1px solid; padding-top: 2px; border-bottom: #7e9db9 1px solid" size="31" name="q" />
    <input type="submit" value="搜索" name="sa" />
  </div>
</form>
 
<script src="http://www.google.com/coop/cse/brand?form=cse-search-box&amp;lang=zh-Hans" type="text/javascript"></script>
<!-- Google Customer serch engine End -->

完。

 

Issue:

Issue1: google自定义搜索引擎的不足,

主要有:       
    1) 索引的建立不稳定,或者说延迟太厉害,经验感受下:          
       1.1 testlist邮件列表的sitemap提交给googl后,第一次是在半小时后能看到效果。 第二次添加一篇文章 ,里面含有"测试GB2312” 这个字符串,我看到google控制台上已经显示该sitemap.xml对应的文章数增加了,我针对这个sitemap 运行了"index Now" 然后过了半小时去搜索"测试GB2312” 依然是没有结果。3小时以后才看到了期望的结果。经过多次试验发现一般在运行"Index Now"以后3小时可完成sitemap中URL对应页面的索引.           
       1.2 report-maillist邮件列表中有很多页面,其sitemap已经在1天前提交给google,由于当时没有点"Index Now",今天在自定义搜索引擎中搜索其中包含的关键词时,还是搜索不到,说明google未曾给它做索引。难道是说如果提交了某个sitemap,而没有手动"Index Now"的话,就不知道google要隔多久才会主动来抓取sitemap中的网页并建立索引了?。

     这个问题其实很严重,因为你跟普通用户去解释全文搜索需要隔N个小时才起作用,很难解释得通,所以,如果使用google自定义搜索引擎作为企业级的正式搜索引擎,可能不妥,因为在用户看来它显得不可靠,但作为一个备用搜索引擎还是可以的。或者作为一个个人站点的邮件列表的搜索引擎也还勉强凑活。

     如果要使用google自定义索引,建议能些个脚本自动为每个sitemap定期运行"Index Now" ,分析"Index Now"页面的源码可以看到其执行的http请求。我们也可以自己执行这些请求,可以为多个sitemap执行"Index Now"

 

http://www.google.com/coop/manage/cse/index?cx=016037023302352540634:y7c8yn6q_ra&amp;hl=zh-CN&amp;sig=__4TuuBdvPw7mRe-F4gl4lRNM-56w=&amp;qauth=kcmf3TVXwKibiK2x&amp;qinfo=zvq2LnMpaIo&amp;sitemap=http://report.retailsolution.cn/mhonarchive/testlist/sitemap.xml.gz
http://www.google.com/coop/manage/cse/index?cx=016037023302352540634:y7c8yn6q_ra&amp;hl=zh-CN&amp;sig=__4TuuBdvPw7mRe-F4gl4lRNM-56w=&amp;qauth=kcmf3TVXwKibiK2x&amp;qinfo=zvq2LnMpaIo&amp;sitemap=http://report.retailsolution.cn/mhonarchive/datafix/sitemap.xml.gz
http://www.google.com/coop/manage/cse/index?cx=016037023302352540634:y7c8yn6q_ra&amp;hl=zh-CN&amp;sig=__4TuuBdvPw7mRe-F4gl4lRNM-56w=&amp;qauth=kcmf3TVXwKibiK2x&amp;qinfo=zvq2LnMpaIo&amp;sitemap=http://report.retailsolution.cn/mhonarchive/handtech/sitemap.xml.gz
http://www.google.com/coop/manage/cse/index?cx=016037023302352540634:y7c8yn6q_ra&amp;hl=zh-CN&amp;sig=__4TuuBdvPw7mRe-F4gl4lRNM-56w=&amp;qauth=kcmf3TVXwKibiK2x&amp;qinfo=zvq2LnMpaIo&amp;sitemap=http://report.retailsolution.cn/mhonarchive/report-maillist/sitemap.xml.gz
http://www.google.com/coop/manage/cse/index?cx=016037023302352540634:y7c8yn6q_ra&amp;hl=zh-CN&amp;sig=__4TuuBdvPw7mRe-F4gl4lRNM-56w=&amp;qauth=kcmf3TVXwKibiK2x&amp;qinfo=zvq2LnMpaIo&amp;sitemap=http://report.retailsolution.cn/mhonarchive/channelproject-commits/sitemap.xml.gz

Over 

不过可惜,这些请求不能直接执行,需要登录。不过在google文档中提供了login的API的。文档参考:我的帐户->我的搜索引擎->文档->开发人员指南。有时间的时候可以继续研究。

      google帐户,有不同级别,不同级别的帐户在使用Index Now功能的时候有不同的限制,一般的帐户提交"Index Now"不管你的SiteMap中有多少条URL,google只会为其中级别最高(如果级别都一样,就是最后更新的)的10个页面建立索引。级别高的帐户可以一次获得更多数量的页面索引,此外"Index Now" 针对一个CSE限制只能一天执行一次(不过你有多少个SiteMap); 这个一天执行一次是官方说法,实际上可以做到每隔1小时执行一次。如果写程序来执行"Index Now"需要试验,因为Google的标准Service API中没有明确支持通过程序执行"Index Now"

            2009-01-31 经过多次测试发现,如果没有手动"Index Now" ,在提交了SiteMap以后经过3天也没有被Google Index进去,真是郁闷,我们总部能每天手动去"Index Now"吧,唉,即使手动去"Index Now" ,Google还做了上面的很多限制,你要靠Google来对你的站点进行全文检索?天大的笑话,真是幼稚。

           看来,即便是一个个人站点的搜索引擎也不能靠Google, 得另寻出路。网上有关于全文检索引擎的资料,下一步研究方向:1、Oracle 商业搜索引擎,2、开源搜索引擎。 对于开源搜索引擎,首先研究:Lucene , 可参考:http://www.chedong.com/tech/lucene.html

mailman 集成 MHonArc 操作指南

mailman 集成 MHonArc 操作指南

mailman 内置的邮件归档程序pipmail ,不能处理mime类型邮件, 一个图文并茂的邮件 ,会被拆分成多个图片,html的邮件也会另存为一个附件。阅读很不方便。那么如何改善呢? 一般建议使用其他的邮件归档程序和mailman集成,下文描述mailman集成MHonArc的步骤:

 

–1)下载并安装MHonArc-2.6.16-1.noarch.rpm
—  请参考: http://www.mhonarc.org/#support
—  下载def-mime.mrc 作为默认的resource 文件
—  请参考:http://www.mhonarc.org/MHonArc/doc/rcfileexs/def-mime.mrc.html

–2)配置mailman 使用MHonArc
—  请参考:http://www.mhonarc.org/archive/html/mhonarc-users/2001-10/msg00021.html
—  在/etc/mailman/mm_cfg.py 中添加:
PUBLIC_ARCHIVE_URL  = ‘/mhonarchive/%(listname)s’
PRIVATE_ARCHIVE_URL  = ‘/mhonarchive/%(listname)s’
PUBLIC_EXTERNAL_ARCHIVER = ‘/usr/bin/mhonarc -rcfile /etc/mailman/def-mime.mrc -add -outdir /var/lib/mhonarc/archives/%(listname)s > /dev/null’
PRIVATE_EXTERNAL_ARCHIVER = ‘/usr/bin/mhonarc -rcfile /etc/mailman/def-mime.mrc -add -outdir /var/lib/mhonarc/archives/%(listname)s > /dev/null’

–3)配置httpd.conf
vi /etc/httpd/conf/httpd.conf
–找到 Alias /icons/ 在下面添加:
Alias /mhonarchive/ “/var/lib/mhonarc/archives/”
<Directory “/var/lib/mhonarc/archives/”>
    Options -Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

–4)建立列表目录
cd /var/lib
mkdir /mhonarc
chown root:mailman mhonarc
cd mhonarc
mkdir archives
chown root:mailman archives
cd archives

mkdir testlist
chown root:mailman testlist
chmod 775 testlist

–所有需要 mhonarc 归档的列表,都需要手动建立对应的目录,改变目录的group,写权限.
–当新建一个mailman 列表时,系统还是会在默认的归档目录中自动建立对应的列表目录,
–但不会在EXTERNAL_ARCHIVER 指定的目录中自动建立对应的列表目录.所以很遗憾,需要手动建立.

–5)重启Apache
service httpd restart

–6)初始化转换
prefix=/var/lib/mailman
export prefix
mhonarc -mbox $prefix/archives/private/testlist.mbox/testlist.mbox -outdir /var/lib/mhonarc/archives/testlist -rcfile /etc/mailman/def-mime.mrc

— 转换后在/var/lib/mhonarc/archives/testlist目录下后会产生一个.mhonarc.db 文件,该文件是def-mime.mrc 模板必须的,要使得mailman 对 此文件有读权限。
— 否则mhonarc运行会报错,归档失败,但不影响邮件发送。要避免这个问题可以如下更改:
chown root:mailman .mhonarc.db

把目录的读写权限设置为:755

chmod 755 /var/lib/mhonarc/archives/testlist

把目录的所有者更改为:root:mailman

chown  root:mailman /var/lib/mhonarc/archives/testlist

 

–所有需要 mhonarc 归档的列表,都需要初始化转化一下.

–7)重启mailman
service mailman restart

–8)问题
    8.1) 从web访问归档时,提示Forbidden ,不允许访问,怎么办?
         答:原因是mailman 使用mhonarc 转换邮件为html的时候, 写文件时, 只有owner和group的读权限,没有other的读权限,所以无法访问.
            最简单的方法就是把 apache用户放入到mailman 用户组下去.
            比如: usermod -G apache,mailman,cvs_project apache
            加入后,需要重启apache.
    8.2) 从web访问归档时, 显示的是目录,而不是默认的归档列表页. 怎么办?
         答: 使用mhonarc 产生的索引文件名是:threads.html 和maillist.html 没有index.html 所以没有显示默认页面.
            最简单的方法,在httpd.conf  中 DirectoryIndex 参数添加 threads.html  
            DirectoryIndex index.html index.html.var threads.html 
            加入后,需要重启apache.
    8.3) 我发现gforge 集成mailman,由Gforge创建的maillist 不受上述改动的影响
         答: 是这样的,在gforge的httpd.conf中,对mailman 别名有自己的定义. 这个问题在有时间的时候可以继续研究.
    8.4) 如果哪天我不想使用mhonarc来归档了,还是恢复到pipmail来归档,那么会有什么问题么?
         答: mailman的逻辑是,先归档到默认的地方,然后查看是否有外部归档程序,如果有,再交给外部归档程序继续归档.所以原始归档总是存在的.
             没有什么问题.
    8.5) 从web访问归档时, 发现来自post-notification的html模版的邮件中的中文是乱码,但是outlook发过来的是正常的.怎么解决?
         答: 在gmail中查原始文件,发现字符集不对,只需要修改post-notification的html 的email模版就可以了.把字符集改成UTF-8.

–9)其他Mailman相关问题

    9.1)如果我原来使用80端口,后来使用:81作为web端口,如何更改以前的列表使得其中的所有链接都带有:81?

          答:按照下面的做法即可实现:

                进入 mailman 目录(一般是/usr/lib/mailman),在其中新建一個文件 (取名为 webdata 好了),內容为:
                web_page_url = ‘http://gforge.retailsolution.cn:81/mailman’
                然后使用
               $ bin/config_list -i webdata yourlist
               命令,你就会得到
               Non-standard property restored: web_page_url
               这就是成功了。

               查看你的管理页面,就会发现里面的链接都已经指向新的域名了。

Subversion快速入门教程(SVN)

Subversion快速入门教程(SVN)

Subversion是新一代的版本控制工具,不仅仅应用于程序源代码管理,也可以广泛应用于其他需要协作管理数据的工作,例如有人使用Subversion来合作写乐谱,美工用来共同作图,文档写作人员一起写一篇大作。
对于希望学习Subversion的新手,可以看看这一篇最快速的Subversion入门教程。
如何快速建立Subversion服务器,并且在项目中使用起来,这是大家最关心的问题,与CVS相比,Subversion有更多的选择,也更加的容易,几个命令就可以建立一套服务器环境,可以使用起来,这里配套有动画教程
本文是使用Subversion最快速的教程,在最短的时间里帮助您建立起一套可用的服务器环境,只需略加调整就可以应用到实际项目当中。
本教程分为以下几个部门,不仅仅是快速入门,最后我们还有一些高级功能的说明,为了说明简单,教程是在windows下使用的方式,以方便资源有限的项目使用,对于UNIX环境下,区别并不大。
软件下载
服务器和客户端安装
建立版本库(Repository)
配置用户和权限
运行独立服务器
初始化导入
基本客户端操作
1,软件下载
下载Subversion服务器程序。 到官方网站的下载二进制安装文件,来到二进制包下载部分 ,找到 Windows NT, 2000, XP and 2003部分,然后选择”this directory“,这样我们可以看到许多下载的内容,目前可以下栽 svn-1.2.3-setup.exe
下载Subversion的Windows客户端TortoiseSVN。 TortoiseSVN是扩展Windows Shell的一套工具,可以看作Windows资源管理器的插件,安装之后Windows就可以识别Subversion的工作目录。
官方网站是TortoiseSVN,下载方式和前面的svn服务器类似,在Download页面的我们选择Official version for Win2k/XP or higher的版本,然后在sourceforge的下载页面选择目前的最高稳定版本的安装文件TortoiseSVN-1.2.4.4479-svn-1.2.3.msi
2,服务器和客户端安装
服务器安装,直接运行svn-1.2.3-setup.exe,根据提示安装即可,这样我们就有了一套服务器可以运行的环境。
安装TortoiseSVN,同样直接运行TortoiseSVN-1.2.4.4479-svn-1.2.3.msi
按照提示安装即可,不过最后完成后会提示是否重启,其实重启只是使svn工作拷贝在windows中的特殊样式生效,与所有的实际功能无关,这里为了立刻看到好的效果,还是重新启动机器。
3,建立版本库(Repository)
运行Subversion服务器需要首先要建立一个版本库(Repository),可以看作服务器上存放数据的数据库,在安装了Subversion服务器之后,可以直接运行,如:
svnadmin create E:svndemorepository
就会在目录E:svndemorepository下创建一个版本库。
我们也可以使用TortoiseSVN图形化的完成这一步:
在目录E:svndemorepository下”右键->TortoiseSVN->Create Repository here…“, 然后可以选择版本库模式, 这里使用默认即可, 然后就创建了一系列目录和文件。
4,配置用户和权限
来到E:svndemorepositoryconf目录,修改svnserve.conf:
# [general]
# password-db = passwd
改为:
[general]
password-db = passwd然后修改同目录的passwd文件,去掉下面三行的注释:
# [users]
# harry = harryssecret
# sally = sallyssecret
最后变成:
[users]
harry = harryssecret
sally = sallyssecret
5,运行独立服务器
在任意目录下运行:
svnserve -d -r E:svndemorepository 我们的服务器程序就已经启动了。
6,初始化导入
来到我们想要导入的项目根目录,在这个例子里是E:svndemoinitproject,目录下有一个readme.txt文件:
右键->TortoiseSVN->Import…
URL of repository输入“svn://localhost/trunk”
ok 完成之后目录没有任何变化,如果没有报错,数据就已经全部导入到了我们刚才定义的版本库中。
7,基本客户端操作
取出版本库到一个工作拷贝:
来到任意空目录下,在本例中是E:svndemowc1,运行右键->Checkout,在URL of repository中输入svn://localhost/trunk,这样我们就得到了一份工作拷贝。
在工作拷贝中作出修改并提交:
打开readme.txt,作出修改,然后右键->Commit…,这样我们就把修改提交到了版本库,我们可以运行。
察看所作的修改:
readme.txt上右键->TortoiseSVN->Show Log,这样我们就可以看到我们对这个文件所有的提交。在版本1上右键->Compare with working copy,我们可以比较工作拷贝的文件和版本1的区别

来源: http://www.ad0.cn/netfetch/read.php/643.htm

动画教程参考:http://www.subversion.org.cn/media/all.swf

subversion VS cvs

subversion vs cvs, 介绍开源的版本控制软件subversion 和 cvs ,比较cvs 和 subversion的优缺点,讲述两者之间的联系,总而言之,subversion 是 cvs的升级版,所以如果要选择,当然是首选subversion.

 

 

CVS

CVS是一个C/S系统,多个开发人员通过一个中心版本控制系统来记录文件版本,从而达到保证文件同步的目的。工作模式如下:

CVS服务器(文件版本库)

CVS(Concurrent Version System)版本控制系统是一种GNU软件包,主要用于在多人开发环境下的源码的维护。实际上CVS可以维护任意文档的开发和使用,例如共享文件的编辑修改,而不仅仅局限于程序设计。CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS用Copy-Modify-Merge(拷贝、修改、合并)变化表支持对文件的同时访问和修改。它明确地将源文件的存储和用户的工作空间独立开来,并使其并行操作。CVS基于客户端/服务器的行为使其可容纳多个用户,构成网络也很方便。这一特性使得CVS成为位于不同地点的人同时处理数据文件(特别是程序的源代码)时的首选。

所有重要的免费软件项目都使用CVS作为其程序员之间的中心点,以便能够综合各程序员的改进和更改。这些项目包括GNOME、KDE、THE GIMP和Wine等。

CVS的基本工作思路是这样的:在一台服务器上建立一个源代码库,库里可以存放许多不同项目的源程序。由源代码库管理员统一管理这些源程序。每个用户在使用源代码库之前,首先要把源代码库里的项目文件下载到本地,然后用户可以在本地任意修改,最后用CVS命令进行提交,由CVS源代码库统一管理修改。这样,就好像只有一个人在修改文件一样,既避免了冲突,又可以做到跟踪文件变化等。

CVS是并发版本系统(Concurrent Versions System)的意思,主流的开放源码网络透明的版本控制系统。CVS对于从个人开发者到大型,分布团队都是有用的:

   它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最 新的代码。它的无限制的版本管理检出(check out:注1)的模式避免了通常的因为排它 检出模式而引起的人工冲突。 它的客户端工具可以在绝大多数的平台上使用。

   CVS被应用于流行的开放源码工程中,象Mozilla,GIMP,XEmacs,KDE,和GNOME等。 那么它到底怎么样?

你可能会说,它非常棒,但是对于”我”来说它能做什么?首先,基本的 :一个版本控制系统保持了对一系列文件所作改变的历史记录。对于一个开发者来说,那就意味着在你对一个程序所进行开发的整个期间,能够跟踪对其所作的所有改动的痕迹。对你来说,有没有出现过由于在令行上 按错键而导致一天的工作都白费的情况呢?版本控制系统给了你一个安全的网络。

版本控制系统对任何人都有用,真的。(毕竟,谁不愿意使用一个安全的 网络呢?)但是它们经常被软件开发团队使用。在团队中工作的开发者需要能够调整他们的各自的修改;一个集 中式版本控制系统允许那样做。

代码集中的配置

个人开发者希望一个版本控制系统的安全网络能够运行在他们的本地的 一台机器上。然而,开发团队需要一个集中的服务器,所有的成员可以将服务器作为仓库来访问他们的代码。在 一个办公室中,没有问题 –只是将仓库连到本地网络上的一台服务器上就行了。对于开放源码项目…噢, 还是没有问题,这要感谢因特网。CVS内建了客户机/服务器存取方法,所以任何一个可以连到因特网上的开发 者都可以存取在一台CVS服务器上的文件。

调整代码

在传统的版本控制系统中,一个开发者检出一个文件,修改它,然后将 其登记回去。检出文件的开发者拥有对这个文件修改的排它权。没有其它的开发者可以检出这个文件 — 并且只 有检出那个文件的开发者可以登记(check in:注2)所做的修改。(当然对于管理员有很多方法可以超越这个 限制。)

想一下排它的检出可能会如何工作:Bob的兄弟检出 foo.java以便加入 注释,写好代码后他什么也没做。然后他去吃午饭了。Bob吃完午饭后,发现他的老板所指给他的一个bug在 foo.java里。他试图检出 foo.java … 但是版本控制系统不允许他这样做,因为他的兄弟已经把它检出了。Bob不 得不等着他的兄弟吃完午饭回来(在这个”好”日子用了两个小时),他才可以修正bug。

在一个大型的开放源码工程中,因为开发者可能在任意的时区工作得很 晚,给予一个开发者阻止任意地方的其它开发者继续处理任意文件的能力很明显示无法运转。他们最终将因为不 能够在他们想要的时候开展项目而感到厌烦。

CVS通过它的无限制的检出模式解决了这个问题。检出一个文件并不给定 开发者对那个文件的排它权。其它的开发者也可以对其检出,进行他们自己的修改,并且将其登记回去。

  ”等一下!”你可能会说。”但是后面的登记不是会覆盖前面的吗?”回答 是不会。详细地回答就是当多个开发者对同一个文件作了修改CVS会检测,并且自动合并那些改变。

到现在为止,你已经毫不犹豫地着迷于CVS 的潜力,并且急不可待地想 开始。第一步就是去得到 适合你的平台的CVS软件。安装CVS通常就是将其从你下载的压缩包中解开这么一件 事。配置CVS 可能要小心一些,它非常依赖于你使用的平台和你的CVS代码仓库的存放地。CVShome.org存放了大 量的CVS 文档:

《Introduction to CVS》 Jim Blandy所写的一篇很棒地在线介绍。我也推荐《 Open Source Development with CVS》 Karl Fogel写的。你可以读一下我写的关 于它的评论在OpenAvenue VOX上。Karl已 经将书中关于CVS的部分置于GPL许可证之下;这篇文档在Karl的站点上以多种文档格式提供。 《The Cederqvist》 — 由Per Cederqvist所编写的CVS手册 — 是一个关于CVS信息的全面资料。  有大量的可用在许多平台上CVS 附加工具,它们给 CVS增加了功能或使得CVS更容易使用。

 

 

subversion

subversion:新一代的开源版本控制工具,CVS的下一代。具有以下特性:

# 具有CVS大多数的当前特性

Subversion意味着更好的CVS,所以它具有大多数CVS的特性。大致说来,Subversion的接口在某些特性上与CVS很类似,若没有特殊原因让你选择其他的解决方式,就采用Subverioin。

# 目录、重命名以及文件元数据都被标示了版本

不具有这些特性是大多数CVS用户所抱怨的。Subversion的版本不仅仅是文件内容以及文件是否存在,还包括目录、副本和重命名。同时它还允许任意的元数据(属性)与任何文件或目录一起标示版本,并且提供了一种用于在文件上标示‘执行’权限标志的版本机制。

# 提交具有真正的原子性

在整个提交没有成功之前任何提交的部分都不会生效。修订(Revision)数量是根据每次提交而定的,并不是每个文件;日志信息附加到了修订内容中,不会像CVS那样冗余。

# 可以选择Apache服务器,使用WebDAV/DeltaV协议

Subversion 可以使用基于HTTP协议的WebDAV/DeltaV协议作为网络通讯协议,并且Apache Web服务器提供了仓库端的网络服务。这就使得Subversion在互操作上比CVS有优势,并且提供了很多免费的关键特性:认证、基于路径的认证、压缩、基本的仓库浏览。

# 可以选择独立运行

Subversion同时也提供了一个以独立服务器运行的选项,它使用自定义的协议(并不是每个人都希望运行在Apache 2.x之上)。独立的服务器可以运行为inetd服务,或者deamon模式,并且提供基本的认证和授权。它可以经由ssh访问。

# 分支(Branching)和标签(Tagging)的开销更小(具有固定的时间)

没有任何理由让这些操作更费时,所以它们必须如此。分支和标签都使用底层的“复制”操作来实现。复制操作使用很小的,固定大小的空间。任何复制都是一个标签;如果你开始提交一个副本,那么它也就会成为一个分支。

# 天然的C/S结构、分层的库设计

Subversion从一开始就被设计成C/S结构的;这样就避免了一些折磨着CVS的维护问题。代码被组织成具有明确的接口的模块,设计成被其他程序调用。

# C/S 协议在两个方向上发送diff

网络协议在两个方向传输diff时能够高效的使用带宽。(CVS发送diff从服务器到客户端,而不是从客户端到服务器)

# 开销与更改的大小有关而不是数据大小

一般而言,Subversion操作所需的时间和操作所导致的结果的大小是成比例的,并不是项目更改发生时的绝对文件大小。这是Subversion仓库模型的一个特性。

# 可选择数据库或者普通文件作为仓库实现

仓库可以使用一个内嵌的数据库支持(BerkeleyDB)或者使用普通的平面文件,两者都使用自定义的格式。

# 给符号连接标示版本

Unix用户可以将符号连接加入版本控制。这些连接可以在Unix中被再次创建,在Win32中则不可以。

# 处理二进制文件更高效

Subversion在处理二进制上和处理文本文件一样高效,因为它使用二进制比较算法传输和存储成功的修订版本。

# 可解析的输出

所有Subversion命令行客户端的输出都是仔细设计成方便人们阅读并且自动解析;脚本具有更高的优先级。

# 本地化消息

Subversion使用gettext()来显示翻译过的错误、报告和帮助信息,基于当前的区域设置。

 

Subversion与CVS的对比——功能性对比

一、Subversion包含绝大部分CVS功能

Subversion 作为CVS 的重写版和改进版,其目标就是作为一个更好的版本控制软件,取代目前流行的CVS。Subversion 的主要开发人员都是业界知名的CVS 专家。Subversion支持绝大部分的CVS 功能/命令;Subversion 的命令风格和界面也与CVS 非常接近。当然,不同的地方正是对CVS 的改进。

二、全局性的版本编号

一个新的版本,并得到一个自增量的版本号N+1,该版本号并不针对某个特定的文件,而是全局性的、针对整个版本库的。因此,我们可以将Subversion 的版本库看作是一个文件系统或文件目录树的数组。

从技术的角度来说,在Subversion 中,“文件foo.c 的第5 版本”这个说法是错误的;正确的说法应该是:”文件foo.c 在版本库被修改了5 次,即执行5 次commit 后是什么样子?”。显然,在Subversion 中,版本库被修改5 次后foo.c 的内容,和被修改了6 次后foo.c 的内容很可能完全一样,因为版本库的第6 次修改很可能只修改了版本库的其他部分,而并没有对foo.c 的进行修改。相反,在CVS 中,文件foo.c 的第1.1 版本和第1.2 版本总是不同的。Subversion 的全局性版本编号为Subversion 带来了诸多的优势:如对目录或文件执行拷贝,无论涉及多少文件,Subversion 不需要对单个文件依次执行拷贝命令,仅仅需要建立一个指向相应的全局版本号的一个指针即可。

三、目录的版本控制

CVS 只能对文件进行版本控制,不能对目录进行版本控制,因此CVS 没有任何关于文件“移动”(move) 操作的概念。当人为进行文件移动操作时,CVS 只能注意到,一个文件在一个位置被删除了,而在一个新位置创建了另外一个文件。由于它不会连接两个操作,因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时,必须非常谨慎地为每个文件选择准确的位置,因为在设置之后,几乎就要一直使用这个位置了。

同样由于CVS 不记录目录的版本历史,CVS 不支持对文件的“重命名”(rename),人为的对文件进行重命名会使得命名前后的文件失去历史联系,而记录历史本来是版本管理的主要目的。还有,CVS 不支持对文件的“拷贝”(copy),人为的拷贝对CVS 而言,只能看到新的文件的增加,而不能记录拷贝源文件和目标文件之间的联系。

综上所述,缺乏对文件“移动”、“重命名”、“拷贝”的支持的根源在于CVS 不能记录目录的版本历史,而这些操作在当前的软件开发过程中经常发生,这正是Subversion被开发并取代CVS 的主要原因之一。

Subversion 将目录作为一类特殊的文件来处理(事实上,从文件系统的角度来看,目录确实是一类特殊的文件,当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时,目录的内容将发生改变)。因此,Subversion 象记录普通文件的修改历史一样记录对目录的修改历史,当发生文件/目录的移动、重命名或拷贝操作时,Subversion 能够准确记录操作前后的历史联系。同样,象对文件的不同历史版本进行比较一样,Subversion支持对目录的不同历史版本的比较,清晰展现目录的变化历史。

四、原子性提交

从使用者的角度来看,CVS 和Subversion 都支持对多个文件修改的批量提交,但二者在实现方式上存在本质的区别。

CVS 采用线性、串行的批量提交,即依次地,一个接一个地执行提交,每成功提交一个文件,该文件的一个新的版本即被记录到版本库中,提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。

CVS 串行批量提交模式的弊端在于 - 当任何原因造成批量操作的中断时(典型原因包括:网络中断、客户端死机等),版本库往往处于一个不一致的状态:原本应该全部入库的文件只有一部分入库,很有可能版本库中的最新版本不能顺利编译,更为严重的是,随着其他的用户执行cvs update 操作,该不一致性将迅速在开发团队中扩散,从而严重影响团队的开发效率,并存在质量隐患。另外,假如该批量提交的中断没有被及时发现,开发团队往往要花更多的时间进行软件调试和排错。

CVS 即使在批量提交不发生中断时也会造成不一致:假设用户A 启动一个需要较长时间才能完成的批量提交;与此同时,用户B 执行cvs update 操作。此时,用户B 很有可能得到一个不一致的更新,即用户B 通过“更新”操作,得到用户A 的部分修改文件。

Subversion 彻底消除了CVS 的以上弊端。无论批量提交包含多少文件修改,只有当全部文件修改都成功入库,该提交才变得有效,才对其他用户可见;否则,无论任何原因造成中断,Subversion 都会自动执行“回滚”(rollback)操作。换一个说法,Subversion 保证所有的修改要么全部入库生效,要么一个也不入库,即对版本库不作任何的修改。这就是Subversion 的原子性提交(atomic commit)。

由于Subversion 的原子性提交特性和全局版本编号方式,当提交成功完成时,一个唯一的、新的全局版本编号产生,而提交时用户提供的日志信息与该新的版本编号关联,只进行一次存储(区别于CVS 的按文件重复存储)。

五、支持变更集概念

由于Subversion 的所有提交是原子性的,每次成功提交形成的唯一的全局版本号对应此次批量提交的所有文件修改,也就是说,一个Subversion 版本号其实对应了一个逻辑上的变更集(change set),该变更集可能对应于对一个BUG 的修复,或者对应于对一个已有功能的改进,或者对应于一个新功能的实现。可以说,变更集是一个软件开发活动的逻辑结果,该变更集可以通过其对应的版本号在软件开发的其他过程中(如软件合并/集成过程,软件发布管理,变更管理系统,缺陷追踪系统)被引用。因此,Subversion 将版本管理从单纯的、单个的文件修改的层次通过逻辑上的抽象,上升到更便于理解和交流的开发活动的层次。

六、差异化的二进制文件处理

由于历史原因,CVS 主要是为早期的程序员设计的,CVS 能够有效处理文本文件(或ASCII文件,源代码文件),可以对文本文件进行差异化的存储、新旧版本的比较,文件合并等;但对于二进制文件,CVS 则明显力不从心。在CVS 的版本库中,对于二进制文件的历史版本,CVS 唯一能做的就是对不同的版本进行独立的、冗余的存储,哪怕版本之间其实只存在微小的差异。举例而言,一个10M 的二进制文件(照片、图形文件、机械设计文件、电子设计文件)假如每周修改一次,无论每次修改的大小,一年下来,仅该文件就要消耗500M 以上的存储空间。而且,客户端每次获取该文件的新版本都要消耗10M 的网络流量。

对于目前的开发团队,无论是软件开发,Web 站点的开发,手机等电子产品的研发,需要进行版本管理的不仅是源代码等文本文件,还需要管理需求文档、设计文档、测试文档、用户手册,图形图像文件,机械/电子设计文件等诸多的二进制文件,CVS 显然不是一个好的选择。

与CVS 不同,Subversion 采用统一的二进制差异算法(binary differencing algorithm),即对文本文件和二进制文件采用相同的差异比较算法,并以相同的方式在版本库中进行存储:每次提交后版本库中只存储相对于先前版本的差异,从而可以节省大量的存储空间。该二进制差异算法不仅应用在版本的存储上,更为重要的是,Subversion 对二进制文件与文本文件一视同仁,当客户端需要获取新的版本时(如执行svn update),在网络上只有版本的差异被传输,从而大大减少对网络带宽的消耗。更多细节参见“七、双向的差异化-压缩网络传输”。

七、 双向的差异化-压缩网络传输

如上所述,CVS 对二进制文件不能进行有效的差异化处理。对于文本文件,CVS 仅仅支持单向的差异化传输:从CVS 服务器到客户端的传输是差异化的,即执行cvs update 时,只有差异的部分从服务器传输到客户端;而当执行cvs commit 时,无论代码变化多少,CVS 都需要从客户端向服务器完整传输被修改文件的全部内容,不能只传输差异。

相反,无论是文本文件还是二进制文件,Subversion 都进行双向的差异化传输,并且差异化内容还要进行压缩/解压缩的过程:在服务器端获取差异显而易见,与CVS 类似;Subversion 在客户端获取差异的秘密在于 — Subversion 在客户端的工作拷贝中隐含了每个文件的一个“只读的、干净的”副本(该副本隐藏在隐含目录.svn 里,通常不可见,该副本还有更多的妙用,参见“十二、更多的本地/离线操作”),通过比较用户在客户端的修改和该隐含的副本,Subversion 获取需要真正传送到服务器的差异,并对差异进行压缩后才进行网络传输。

对CVS 而言,操作的成本(网络带宽消耗是最大的操作成本)与被修改的文件的大小成比例,而与修改本身的大小无关;对Subversion 而言,操作成本只与修改本身的大小成比例,而与被修改的文件的大小无关。因此,与CVS 相比,Subversion 消耗更少的网络带宽(以客户端的存储空间换取更少的带宽消耗在目前的计算环境下应该是个相当不错的选择!)。Subversion 更加适合基于互联网(或广域网)进行协作开发的地理上分布的团队 — 版本服务器集中、单一;客户端广泛分布。

八、高效、快捷创建分支和基线

CVS 和Subversion 都支持分支(branch)和基线(tag),通过分支与合并,可以有效支持大项目的并行开发模式;通过基线管理,可以准确标识一组文件的版本,有效进行软件发布管理和必要时的历史回溯。

但CVS 和Subversion 在实现分支和基线的方式上存在很大的不同。CVS 在创建分支的时候,需要对所有进行分支的文件进行依次的操作,因此分支的建立成本(主要是建立分支所需的时间,或消耗的计算资源)与参与分支的文件数量成比例,项目越大,版本库越大,文件越多,分支的建立成本越高;基线(tag)的建立与此类似。

Subversion 的分支和基线是通过执行“拷贝”来建立的:回想一下在没有引入版本管理工具的时候我们是如何进行所谓的“分支”和“基线”管理的?答案显然是“拷贝” — 我们通过“拷贝”或“备份”来建立基线;同样,为支持多个开发人员可以同时进行开发,我们为每个开发人员创建一份“拷贝”。由此看来,Subversion 通过“拷贝”来建立分支和基线显得非常自然,有点“返朴归真”的意思。

由于Subversion 的全局版本号特性,Subversion 中分支或基线的创建过程,或Subversion中的“拷贝”过程,真正的操作是在版本库中创建一个到某一全局版本号的指针(pointer),不再需要针对众多的单个文件依次执行操作。因此,该操作的成本为一个很小的常数,与项目大小,版本库大小,文件数目的多少无关;并且,分支或基线的建立不需要进行版本的冗余存储,新建立的分支或基线基本不占用版本库空间,分支的后续存储空间的开销也只与修改的大小有关。

九、集成Apache Web Server,提供更多的特性

Subversion 通过与Apache Web Server 的集成,可以提供基于http/https 协议的版本库访问机制,从而支持Subversion 跨越防火墙的安全访问。除此以外,Subversion 还可以利用更多的Apache 特性,包括但不限于:Apache 丰富的用户认证机制(包括通过LDAP服务器如Windows Active Directory 服务器的用户认证),基于目录路径的精细粒度的访问控制,对传输的网络流量进行压缩/解压缩,浏览版本库目录结构等等。

Elliotte Rusty Harold 介绍了 Subversion —— 一种开放源码、多用户版本控制系统,支持非 ASCII 文本和二进制数据。通过 Elliotte 的介绍,您可看到如何在 Eclipse 中配置 Subversion 支持(通过 Subclipse 插件)、检出一个项目、与您的存储库同步,随后执行一些常用的操作,如合并、修补、比较和删除。

版本控制

版本控制之于程序员,就好比安全网之于高空秋千表演者。知道安全网就在那里,万一自己摔落它能够提供保护,高空秋千表演者才能放心大胆地在空中飞跃。同样,版本控制使您有能力去冒以往想都不敢想的风险。如果哪儿出了错,您总是可以使自己的代码回复到一个已知的、工作正常的版本。您可以在不触及主干的分支中进行试验,而不会影响到其他小组成员。在已经发布的产品的较老版本中发现 bug 时,您可以轻松检出特定版本,以确认、修订,并生成该 bug 的修补程序。如果没有版本控制,您必须极为慎之又慎,缓慢地推进,总而言之,生产力会更低。

Subversion 是一种开放源码的全新版本控制系统,支持可在本地访问或通过网络访问的数据库和文件系统存储库。不但提供了常见的比较、修补、标记、提交、回复和分支功能性,Subversion 还增加了追踪移动和删除的能力。此外,它支持非 ASCII 文本和二进制数据,所有这一切都使 Subversion 不仅对传统的编程任务非常有用,同时也适于 Web 开发、图书创作和其他在传统方式下未采纳版本控制功能的领域。

本文介绍了使用 Subversion 追踪项目的基础知识,以使您在编写代码时能够承受更多的风险、享受更多的乐趣。

参考资料 部分)。

在开放源码程序员间,CVS 已成为一种事实上的 标准。Codehaus、Sourceforge、Savannah 和 Java™ 社区的 java.net 等站点中驻留的免费 CVS 使得为开源项目建设存储库更为简单。以 CVS 为中心,已发展起一个大型的附件市场,包括 TortoiseCVS、ViewCVS 和 Fisheye 等工具。

与其他版本控制系统相比,CVS 最令人称道的地方就是其非锁定 存储库,这使多个开发人员能够同时检出同一个文件。CVS 在提交时解决冲突问题,这就避免了冲突成为发展的瓶颈。CVS 第二个出色的特性就是它是一种网络存储库。处于许多不同系统上的程序员可以通过公共的 Internet 访问相同的存储库。

逐渐失去优势的 CVS

CVS 已经不再适合现代开发,这一点越来越明显。特别是 CVS 只能满足老式 C 程序员的 ASCII 需求,而对 Web 开发人员和其他非传统用户来说,CVS 实际上根本不起作用。在您开始考虑存储整个 Web 站点时,在 CVS 中,将文件从一个目录移动到另外一个目录是关键考虑事项。因此,在几年前,许多核心 CVS 开发人员认为,已经到了利用他们多年来使用 CVS 时学到的经验和教训、从头开始创建新一代开放源码存储库的时机。在 2004 年年初,他们的努力结出了丰硕的果实,那就是 Subversion 1.0。

Subversion 的支持与采纳

程序员(特别是那些依赖版本控制的程序员)是一个非常谨慎的群体,Subversion 着实用了很长一段时间,才得到他们的广泛接受。很少有程序员愿意冲在易于流血的最前沿,即便是他们已经因为 CVS 受了伤。甚至是在 Subersion 变得可靠之后,仍然用了好几年的时间,所有第三方编辑器、IDE 和文档规范才相继跟进。而 Subversion 依然在不断改进,BBEdit 和 Eclipse 等第三方工具现在已经有了足够好的 Subversion 支持。逐渐地,新项目也纷纷选择 Subversion 满足其版本控制需求,而老项目正在向 Subversion 移植。最近,Apache Software Foundation 已移植到 Subversion。已实现移植的项目包括 Xerces XML 解析器、Apache HTTP Server 和 Spamassassin。

通过 IDE 使用 Subversion,请见:http://www-128.ibm.com/developerworks/cn/java/j-subversion/index.html

结束语

对于内部存储库,Subversion 提供了远超过 CVS 的改进。如果添加了某种类型的彻底消除功能,它也应同样适于外部存储库。尽管像 Eclipse 这样的工具对 Subversion 的第三方支持还不像 CVS 支持那样普遍,但形势正在迅速地发生变化。Subversion 会成为新项目的默认源代码存储库。尚无源代码控制的现有项目应尽快检入 Subversion。而已有 CVS 存储库的现有项目可能仍在观望,希望等到他们所依赖的全部工具均全面支持 Subversion 后再进行切换。但这些项目最终也会移植到 Subversion。Subversion 中的改进如此显著,令人难以忽略。未来必将属于 Subversion。

来源: http://fayfaykong.blog.163.com/blog/static/171453442007114112527881/