易栈网-膘叔

关于版本控制

什么是版本控制？我真的需要吗？版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们仅对保存着 软件源代码的文本文件作版本控制管理，而实际上，你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本。采用版本控制系统（VCS）是个明智的选择。有了它你就可以 将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出是谁最后修改了什么地方从而造成某些怪异问 题，又是谁在何时报告了某个功能缺陷，等等。使用版本控制系统通常还意味着，就算你胡来搞砸了整个项目，把文件改的改，删的删，你也可以轻松恢复到原先的 样子。而由此额外增加的工作量却微乎其微。

本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，不过坏处却不少：有时候会混 淆所在的工作目录，弄错了文件丢了数据就没了后退的路。

。。。。。。更多看全文

» 阅读全文

以前，为了保证本地的代码与服务器一样，一般都是采用sVN+分支，审核并最后推送到服务器的。当然，也有服务器从svn服务器拉数据的时候。当然这样配置起来是有点繁琐，但还算能用。
shawphy推荐的这个工具，感觉好象不错。如果有兴趣，大家可以尝试尝试。
以下就是shawphy写的文章：让服务器自动从Hg版本库中下载代码

每次写完代码，提交到版本库，测试可以执行不会冲突，推到远端代码仓库。之后要发布的话，还要通过FTP上传到服务器上，FTP速度又不很理想，严重影响工作效率。

有没有解决之道？有！

直接让服务器从代码仓库中下载代码不就行了么？代码仓库中已经包含最新代码了，让服务器从代码仓库的服务器远程下载代码，方便快捷全自动！

而且，现在用的是hg，而不是svn。svn有个问题，提交的代码可能是未完成的半成品导致程序无法执行。而hg的好处是半成品可以提交在本地，阶段性成果完成后再往远端代码仓库中提交。

下面就以使用BitBucket为例，其他服务大同小异。

编译 hg

首先需要在服务器端编译一份 hg ,编译起来还是很方便的，直接从官网下载一份源码，解压缩后make && make install 一下就行了。他源码包里的README里就这么写的。

Mercurial/Hg 下载地址

第一次clone

第一次使用需要先clone一份代码仓库到本地，以后就可以简单的使用pull命令获取更新了。
所以第一次使用需要 hg clone <你的仓库地址>
仓库地址可以在 BitBucket里的项目里找到。

编写 PHP

然后在服务器端写一个文件up.php，放在需要更新的目录下面， 如下代码：

以我的空间为例，就是：

其中最关键的一步是要把密码也写在URL里，否则的话就得用popen()函数来处理密码交互了，比较麻烦。

这样，只要访问这个php文件，就能更新这个网站了。

配置Hook

然后，只需要在 BitBucket 项目管理中，Admin标签里，右边Additional options/settings面板下找到Services，点进去。然后添加一个POST服务，URL地址就填写你那个PHP文件的地址就可以了。

这样就能实现往代码仓库中提交代码后，网站服务器自动下载并更新代码了。

其他

如果要自己搭建的服务器上配置的话，参考 Hg 官方Wiki

---EOF---
用这种类似的工具的好处就是不怕文件改动再多，也会上传修改后的。如果没有版本控制，恐怕代码会乱的一塌糊涂吧，而且，如果有多人同时修改文件，最后会更迷茫。不过总算有这些解决之道。听说GIT不错，还没有研究过。。。

SVN给开发带来了方便，但在导出的时候，如果选择了checkout，那么目录里是带有.svn目录的，除非是export。

如果您的项目中是checkout的，如果还要export，那就烦了一点。因为export是从服务器上导回来的。如果服务器速度慢（网上的免费SVN服务器），那就更痛苦了。因此直接删除.svn目录是最快的解决方法。

windows下面可以直接搜索.svn，然后delete就行了
linux下面怎么办？

其实更方便，只要一句话
进入项目目录后，运行 find . -name ".svn" | xargs rm -rf
然后你就会发现。.svn目录全没有了。HOHO

查了一下google，发现还有另外一个方法：

最近关于SVN的资料，一直都是粘贴网上的信息到勃客上来。
现在再放上SVN中文资料。可以对照着看看。。。

同样，是一篇摘录，笔记。勿怪。。。
原文：http://www.cnblogs.com/chenlong828/archive/2008/09/22/1296193.html
作者：dreamland

查阅了一下网络和博客园，发现还没有一个明确地指导源码管理提交准则的相关文章，因此斗胆整理了一部分自己平时开发管理的心得，加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。

负责而谨慎地提交自己的代码

SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。

如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。

如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。

保持原子性的提交

每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。

不要提交自动生成的文件

Visual Studio在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用Delete命令从仓库中删除。

不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

不要提交自己不明白的代码

代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

提前宣布自己的工作计划

在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。

对提交的信息采用明晰的标注

+) 表示增加了功能

*) 表示对某些功能进行了更改

-) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。

b) 表示修正了具体的某个bug