subversion – 夏清然的日志 https://www.qingran.net Xia Qingran Geek Blog Sun, 07 Aug 2016 09:50:33 +0000 en-US hourly 1 https://wordpress.org/?v=4.6.1 112893047 版本控制再思考 https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/ https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/#comments Mon, 15 Nov 2010 17:37:15 +0000 https://www.qingran.net/?p=711 最近必须解决Version Control的问题了，目前使用的svn，并采用主干活跃，分支稳定的开发策略（平时的修改都在trunk进行，主干版本发布后需要修改bug才创建分支，并在分支工作，完成后merge主干），目前发现和想到的问题有以下几点：

  1. 版本库过大导致检出代码太慢（3个月过去有7000+版本，检出一次50GB）；
  2. 平时工作代码的提交都在主干进行，所以主干必须能够编译，由此引出以下问题：
    • 复杂的模块儿完成时间较久，成员很久都不提交，并且提交后这段时间没有自己的修改历史日志；
    • 成员机器的硬盘在这个长时间有可能挂掉，导致工作成果丢失的风险；
  3. 成员之间交换工作成果通过svn在主干进行，违背了主干 必须能编译，并导致大量的垃圾提交。

针对以上问题目前想到的解决方法：

  1. 改用分布式版本控制工具，Mercurial和GIT，准备分别试一下；
  2. 充分利用分布式管理工具创建分支容易，速度快的特点：
    • 每个人都创建属于自己的分支，平时的工作都在分支上进行，并定期（阶段成果完成后）向主干合并
    • 自己的修改每步都可以commit到本地，每天push一次
  3. 分离美术和程序的svn目录：美术的svn目录定期干掉头1000版本。

做到以上几点后，所有提出的几点问题都应该迎刃而解。这样每个人接到工作任务后的操作顺序是以下几步：

  1. 创建属于自己的分支，可以按季度创建；
  2. 平时的工作都在此分支上进行，同时自己的每步重大修改都commit；
  3. 2天或3天视工作进度和其他人对你工作部分代码的需求而push到远程库；或者在放假前需要对代码做备份防止硬盘挂掉，也push分支工作成果到远程库；
  4. 任务完成后，测试通过后，从分支merge到主干；
  5. 新季度开始，回到操作1。

完成，临睡觉前粗糙的想了一下，应该还有很多不足之处，希望看见的兄弟多指正。

]]> https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/feed/ 2 711 SVN转换Mercurial，Mercurial的安装 https://www.qingran.net/2010/11/svn%e8%bd%ac%e6%8d%a2mercurial%ef%bc%8cmercurial%e7%9a%84%e5%ae%89%e8%a3%85/ https://www.qingran.net/2010/11/svn%e8%bd%ac%e6%8d%a2mercurial%ef%bc%8cmercurial%e7%9a%84%e5%ae%89%e8%a3%85/#comments Mon, 15 Nov 2010 16:19:11 +0000 https://www.qingran.net/?p=706 背景：目前的项目使用的版本控制是SVN。只建立了一个svn库并使用bdb模式。项目开始了3个月，svn的版本号就突破了7000，svn库在服务器端有9GB。而在windows下用TortoiseSVN检出所有的东西，总共近50GB大小（.svn目录貌似保留了所有的历史），居然需要3个小时以上！实在忍不了了，准备换分布式VC。目前暂时选择Mercurial。


首先需要把svn转换为Mercurial，同时还要把svn库分离一下，系统是ubuntu-10.04 server amd64：

#apt-get install mercurial meld python-subversion

#svnadmin dump ./repos/ > svn.dump

#wget http://bakacsin.ki.iif.hu/~kissg/project/svn/svngrep


#./svngrep '^dev\/core\b' svn.dump > core.dump

svngrep有重大问题，导致其导出的不全，改用svndumpfilter


#cat svn.dump | svndumpfilter include dev/core --drop-empty-revs --renumber-revs  > core.dump
#svnadmin create core/
#sed -r -e 's/^Node-path: dev\//^Node-path: /' core.dump > core.dump.new
#svnadmin load core < core.dump.new

# cat /root/.hgrc
[extensions]
hgext.convert =

#hg convert file:///data/test/core/

#mkdir -p /var/mercurial/

#mv /data/test/core-hg /var/mercurial/

#chown -R www-data:www-data /var/mercurial/

#chmod -R 700 /var/mercurial/


然后建立Mercurial：


# mkdir /var/www/cgi-bin/
# cp /usr/share/doc/mercurial/examples/hgweb.wsgi /var/www/cgi-bin/
# cat /var/www/cgi-bin/hgweb.config
[web]
style = coal
allow_push = *
push_ssl = false

[paths]
/ =  /data/mercurial/**

#chmod +x /var/www/cgi-bin/hgwebdir.wsgi


修改 /var/www/cgi-bin/hgwebdir.wsgi 文件，最后一行的“application = hgwebdir(‘hgweb.config’)“修改为：


application = hgwebdir('/var/www/cgi-bin/hgweb.config')


配置apache2，使之运行wsgi模式的Mercurial:


#apt-get install libapache2-mod-wsgi


在需要加入的VirtualHost里加入：


WSGIScriptAliasMatch ^(.*)$ /var/www/cgi-bin/hgwebdir.wsgi$1
<Directory "/data/mercurial/">
	Options FollowSymlinks
	DirectoryIndex index.html
	AuthType Basic
	AuthName "Subversion Repository"
	AuthUserFile /etc/apache2/dav_svn.passwd
	Require valid-user
</Directory>

<Directory "/var/www/cgi-bin">
	Options ExecCGI FollowSymlinks
	AddHandler wsgi-script .wsgi
	AuthType Basic
	AuthName "Subversion Repository"
	AuthUserFile /etc/apache2/dav_svn.passwd
	Require valid-user

</Directory>


重启apache2，然后就开始使用吧。

]]>
https://www.qingran.net/2010/11/svn%e8%bd%ac%e6%8d%a2mercurial%ef%bc%8cmercurial%e7%9a%84%e5%ae%89%e8%a3%85/feed/
1
706 

Apache2 KeepAlive详解 + subversion优化
https://www.qingran.net/2010/07/apache2-keepalive%e8%af%a6%e8%a7%a3/
https://www.qingran.net/2010/07/apache2-keepalive%e8%af%a6%e8%a7%a3/#comments
Thu, 08 Jul 2010 17:23:03 +0000










https://www.qingran.net/?p=502

由于现在subversion的数据有10GB之多，并且一次checkout会有10w个文件之多，所以这两天看如何优化一下我们的subversion，其中一个点就是apache2的keep alive参数。




Apache Keep-Alive扩展源自自HTTP/1.0和HTTP/1.1标准的的持久链接特性。提供了相对长效的HTTP链接方式，用以在同一个TCP连接中进行多次HTTP请求。KeepAlive设置出现在Apache 1.2版本以后。


对于HTTP/1.0的客户端来说，仅当客户端指定使用的时候才会使用持久链接连接。此外，仅当能够预先知道传输的内容长度时，才会与HTTP/1.0的客户端建立持久链接连接。而对于HTTP/1.1的客户端来说，如果没有进行特殊指定，持久将是默认的连接方式。如果客户端进行了请求，将使用数据分块以解决在持久链接里发送未知长度内容的问题。


KeepAliveTimeout的设置说明：

Apache在关闭持久连接前等待下一个请求的秒数。一旦收到一个请求，超时值将会被设置为Timeout指令指定的秒数。

对于高负荷服务器来说，KeepAliveTimeout值较大会导致一些性能方面的问题：超时值越大，与空闲客户端保持连接的进程就越多。


MaxKeepAliveRequests的设置说明：

MaxKeepAliveRequests指令限制了当启用KeepAlive时，每个连接允许的请求数量。如果将此值设为”0″，将不限制请求的数目。我们建议最好将此值设为一个比较大的值，以确保最优的服务器性能。


通过Apache的设置说明，我们明白在对于一个包含许多图片、css、js的静态内容网页， 客户端会在瞬间发出多个HTTP请求，此时多次建立TCP连接会大大降低响应速度且耗费服务器端资源。 此时通过持续连接，可以允许用户在一个TCP连接中发出多个HTTP请求， 减少TCP连接建立次数，提高响应速度。我们可以通过access log统计出连续HTTP请求出现的次数、间隔时间、访问量， 以确定 MaxKeepAliveRequests 和 KeepAliveTimeout 的值。 KeepAliveTimeout 太小发挥不了持续连接的作用；太大了，该断开连接迟迟的在等待，不仅浪费TCP连接数，而且系统中的apache2的进程数目会因此不断增加，使得系统负载升高。


哪么什么决定着我们是不是要开启KeepAlive的因素就很简单了：就是用户一个页面请求中是否会引发向同一个apache2服务器发出多个HTTP的请求。


但是当你的服务器只是在处理动态网页请求时，由于用户很少会瞬间请求多个动态网页（一般都是打开页面之后阅读好半天才点下一页），此时打开KeepAlive无异于浪费TCP连接数。所以此时应该把KeepAlive off之。


而对于提供静态文件服务，例如图片或静态文件服务，如果一用户需要同时从这个服务上得到数个甚至数十个文件，那么KeepAlive不仅仅能减少TCP的链接请求，更能节省apache2的进程资源。

而对于subversion，由于是一个HTTP同步一个文件，所以特别需要KeepAlive的支持，以下是我的配置：


KeepAlive on
KeepAliveTimeout 5
MaxKeepAliveRequests 0
MaxRequestsPerChild 1000

]]>
https://www.qingran.net/2010/07/apache2-keepalive%e8%af%a6%e8%a7%a3/feed/
2
502