如何处理Subversion
Subversion是管理位于
http://sourceforge.net上的Gambas源代码仓库的软件。
仓库很类似一个文件系统,并且可以保留所有的修改。
Gambas仓库结构
Gambas仓库分为3个主要目录:
/trunk
|
该目录包含发展版的源代码,它的目标是演进成Gambas的下一个主要版本(3.0)。
|
/branches
|
该目录包含稳定版的源代码。每一个稳定版在这里都有一个对应的子目录。它们的目标是演进成稳定版的下一个次版本(2.X)。
一旦发现处于=/trunk=之外的一些其他的Gambas相关发展设计,将来会被合并进发展版。
|
/tags
|
该目录包含Gambas的每一个发布版源代码。每一个版本在这里都有一个对应的子目录。它们仅仅是存档,并被用于旧版本的改造。
|
可以在
http://gambas.svn.sourceforge.net/viewvc/gambas/gambas看到仓库的内容。
获得Gambas仓库的写入访问权限
每个人都可以用下面的命令在自己的硬盘上建立一个仓库的拷贝:
$ svn checkout https://gambas.svn.sourceforge.net/svnroot/gambas/gambas/trunk/
或者用:
$ svn checkout https://gambas.svn.sourceforge.net/svnroot/gambas/gambas/branches/2.0
获取稳定版。
注意在仓库路径前面的前缀:
https://gambas.svn.sourceforge.net/svnroot/gambas/gambas/
但是如果想参与Gambas的开发和翻译,那就需要对仓库进行*写入*访问。
要想这样,仅仅需要在sourceforge.net创建一个用户帐户,并且要求我给这个新创建的用户写入访问的权限。
它怎样工作?
仓库中任何东西的每一次改变,需要增加/修订号/并且附加上一个/修订日志/。完成修改的人负责编辑修订日志。
用=svn=命令完成这些工作。
-
svn checkout
在你的硬盘上建立仓库的一个拷贝,并添加一些隐含的=.svn=目录,在其中存放对修改的跟踪。
-
svn commit
将修改全部发送回服务器,请求修订日志并增加修订号。每一个提交都有属于自己的修订号和修订日志。
-
svn update
升级仓库的本地拷贝到最新版本。
某些人可能会在你/检查/和/提交/之间的这段时间修改了某些东西。所以在进行=svn commit=之前应该先进行=svn update=。
写修订日志
提交时,必须在环境变量=$EDITOR=中指定用于编辑修订日志的编辑器。
例如:
$ EDITOR=gedit svn commit
注意,提交后就不能再修改修订日志。看起来sourceforge的这个特性失效了。所以,要小心!
修订日志的格式
我想使用标准方法书写提交信息,那样就差不多可以自动生成变更日志(ChangeLog)。
格式如下:
-
一个变更日志节:用'
[
'和']
'括起来
-
一个变更日志变更: 一个'
*
',一个空格,字'BUG
'、'NEW
'或'OPT
',一个冒号,一个空格,文本。
'
BUG
'是一个修复,'
NEW
'是一个新特性、翻译或更新,'
OPT
'是一个优化。
节是大写的组件名字或下列内容之一:
-
[INTERPRETER]
-
[COMPILER]
-
[ARCHIVER]
-
[INFORMER]
-
[DEVELOPMENT ENVIRONMENT]
-
[DATABASE MANAGER]
-
[CONFIGURATION]
-
[WIKI CGI SCRIPT]
所有的行长度必须小于等于76个字符。
如果一个变更日志修改项多于一行,必须使用两个空格的缩进。
空行会被忽略。
其他的所有行不会进入变更日志。
Examples
我做的这些事,并且该行不会进入变更日志。
[GB.QT]
* BUG: 我修复了这个错误。
* NEW: 我写了很长的变更信息....
太多了,一行写不下,所以另起一行写在这里。
该行也不会进入变更日志。
[GB.SDL]
* BUG: 一个可怕的错误是....!
[GB.GTK]
* NEW: 我终于完成了组件 :-)
请遵守这个方案。这会*真的*很酷...
提交的邮件列表
每次某人提交了新版本,邮件列表的邮箱就能接到一封邮件。所以这样你总是能知道你硬盘上的版本是不是最新的。
去
邮件列表页面可以订阅这个邮件列表。邮件列表的名字是=Gambas Subversion Commits=。
仓库拷贝的状态
运行=svn status=命令,可以获得你的仓库拷贝的状态。
每个状态用下列的一个或多个字符描述:
-
?
不受subversion管理的文件。
-
M
已被修改的文件。
-
C
冲突的文件。
-
G
被=svn=命令自动解决的冲突文件。
-
A
新添加的文件或目录。
-
D
删除的文件或目录。
-
... 等等。
关于/冲突/的更多信息看后面部分。
警告
工程结构不会自动进行跟踪
必须用下面的命令告诉subversion你是否添加、删除、重命名或移动了某个文件:
-
svn add
添加已经创建的文件。
-
svn del
删除文件。
-
svn move
重命名或移动文件。
忘记使用=svn add=是一个常见得错误。我告诉你我所知道的。 :-)
冲突
某些人可能在你修改你硬盘中的某个文件的同时在修改仓库中相应的文件。 这就产生了/冲突/,而且=svn=会在运行=svn status=或=svn update=命令时会报告这个冲突。
每当存在冲突,=svn=试图通过合并你和别人的修改来自动解决它。
如果合并成功,会得到标示有'G'状态字符的文件。
如果合并失败,会得到标示有'C'状态字符的文件。那么你就不得不手工来解决冲突:
-
你必须亲自编辑文件以合并修改。=svn=有修改的文件,所以你可以对照查看你和别人的修改。
-
或者你可以使用subversion生成的自动拷贝之一。获取一个最新的版本和一个本地仓库的当前版本。它们的名字是原始的文件名加一个逗点、字符'r'和修订号。仅仅通过复制来替换原始文件。
一旦这样做,将通过对冲突的文件运行=svn resolved=命令告知=svn=冲突已经解决。
有无什么风险?
正常情况下没有风险,所有的都被存档,所以总是能恢复到以前。
而且,如果你在仓库内部的Gambas工程上工作,开发环境能为你处理所有的=svn=命令。进入工程属性对话框中的/版本/标签,可以找到允许你升级工程、提交和取消你的修改的按钮。
如果有某些奇怪的事情,你可以用=svn revert=命令,恢复你的本地拷贝到最近一次检查或升级的状态。