@@ -35,6 +35,8 @@ SVN脱库的工具SVN本身就提供: ``svnsync`` 。这个工具主要用于S
35
35
有人认为SVN可以对目录授权,从而阻止对整个版本库进行脱库操作。
36
36
下面就来看看SVN的授权究竟是否可靠。
37
37
38
+ <a name =' svnauthz ' id =' svnauthz ' ></a >
39
+
38
40
### 误解2:SVN能对目录进行精细授权,而Git太不安全 ###
39
41
40
42
SVN的目录授权对管理员来说是灾难,管理负担相当重,在分支或里程碑众多的时候很难作对。
@@ -45,20 +47,20 @@ SVN的目录授权对管理员来说是灾难,管理负担相当重,在分
45
47
[demo:/trunk]
46
48
@demo-admin = rw
47
49
@leaders = r
48
-
50
+
49
51
[demo:/trunk/doc]
50
52
@demo-dev = rw
51
53
@designers = rw
52
-
54
+
53
55
[demo:/trunk/src/apps]
54
56
@demo-dev = rw
55
-
57
+
56
58
[demo:/trunk/src/common]
57
59
@demo-dev = rw
58
-
60
+
59
61
[demo:/trunk/src/html]
60
62
@designers = rw
61
-
63
+
62
64
[demo:/trunk/src/secret]
63
65
* =
64
66
@demo-admin = rw
@@ -70,20 +72,20 @@ SVN的目录授权对管理员来说是灾难,管理负担相当重,在分
70
72
[demo:/branches/1.x]
71
73
@demo-admin = rw
72
74
@leaders = r
73
-
75
+
74
76
[demo:/branches/1.x/doc]
75
77
@demo-dev = rw
76
78
@designers = rw
77
-
79
+
78
80
[demo:/branches/1.x/src/apps]
79
81
@demo-dev = rw
80
-
82
+
81
83
[demo:/branches/1.x/src/common]
82
84
@demo-dev = rw
83
-
85
+
84
86
[demo:/branches/1.x/src/html]
85
87
@designers = rw
86
-
88
+
87
89
[demo:/branches/1.x/src/secret]
88
90
* =
89
91
@demo-admin = rw
@@ -136,9 +138,14 @@ SVN也允许配置为可修改历史提交说明,但是一旦管理员放开
136
138
我为客户配置的Git支持HTTP、SSH协议,和Gitweb。其中HTTP协议、Gitweb都使用LDAP认证,
137
139
实现统一的口令管理。并且无论是HTTP协议、SSH协议,还是Gitweb都使用同一套Gitolite授权。
138
140
139
- ### 误解6:SVN更易上手,Git太难了 ###
141
+ <a name =' workflow ' id =' workflow ' ></a >
142
+
143
+ ### 误解6:SVN更易上手,更易管理;而Git太难和太灵活了,不适合团队? ###
144
+
145
+ 如果想把配置管理做好,无论是 SVN 还是 Git 都不容易,否则 [ 《SVN Book》] ( http://svnbook.red-bean.com/ )
146
+ 以及我写 [ 《Git权威指南》] ( http://gotgit.github.com/gotgit/ ) 也不会有那么厚了。
140
147
141
- 如果想把配置管理做好,SVN并不容易,否则 [ 《SVN Book》 ] ( http://svnbook.red-bean.com/ ) 也不会有那么厚了。
148
+ 觉得SVN更简单的,看看下面的错误你有没有犯?
142
149
143
150
* 很多公司的SVN版本库没有遵照约定俗成的三个顶级目录。
144
151
* 如何配置SVN悲观锁,以便更好地对二进制文件编辑进行协同。
@@ -148,7 +155,37 @@ SVN也允许配置为可修改历史提交说明,但是一旦管理员放开
148
155
* SVN管理员如何对版本库进行整理,如撤出不当提交、修改错误的提交说明。
149
156
* 版本库的安全性问题,如何做好版本库的备份。
150
157
151
- Git的设计模型非常简单,理解了其设计思想,就可以很容易地掌握 `` git reset `` ,
158
+ SVN对分支当做路径来授权,造成管理的负担(参见 [ 前面的描述] ( #svnauthz ) ),
159
+ 因此使用SVN实现灵活的特性分支开发、可靠的发布控制(维护分支冻结)很难。
160
+
161
+ 企业应用Git的困惑之一是如何裁剪出适合自己的工作流。实际上Git本身已经给出范例:
162
+
163
+ $ git help workflows
164
+
165
+ 理解Git的应用模型并选用合适的服务器端软件(如 Gitolite),可以定制出适合自己的工作流。
166
+ 例如下表就是在企业中使用Git版本控制系统的典型角色划分:
167
+
168
+
169
+ | | 系统管理员 | 配置管理员 | 发布工程师 | 整合工程师 | 模块负责人 | 开发工程师
170
+ |---------------------------------|:-----------------------:|:----------:|:------------:|:------------:|:----------:
171
+ | | (SYSadm) | (SCMadm) | (RELeng) | (INTegrator) | (MODmaster) | (DEV)
172
+ | 创建版本库 | | ✔ | | | |
173
+ | 版本库授权 | | ✔ | | | |
174
+ | 版本库改名 | ✔ | ? | | | |
175
+ | 删除版本库 | ✔ | ? | | | |
176
+ | 创建Tag | | | ✔ | | |
177
+ | 删除Tag | | ✔ | | | |
178
+ | 创建一级分支 | | ✔ | | | |
179
+ | 为分支授权 | | ✔ | | | |
180
+ | 向 maint 分支强推 | | ✔ | | | |
181
+ | 向 master 分支强推 | | ✔ | | | |
182
+ | 向 maint 分支写入 | | | ✔ | | |
183
+ | 向 master 分支写入 | | | | ✔ | ✔ |
184
+ | 创建个人专有分支 | | ✔ | ✔ | ✔ | ✔ | ✔
185
+ | 创建个人专有版本库 | | ✔ | ✔ | ✔ | ✔ | ✔
186
+ | 为个人专有版本库授权 | | ✔ | ✔ | ✔ | ✔ | ✔
187
+
188
+ 再来谈谈Git的使用,实际上Git的设计模型非常简单,理解了其设计思想,就可以很容易地掌握 `` git reset `` ,
152
189
`` git checkout `` , `` git rebase `` , `` git push `` , `` git pull `` 等命令。
153
190
154
191
### 误解7:程序员不喜欢命令行 ###
@@ -210,7 +247,7 @@ Git的基于DAG(有向非环图)的设计比SVN的线性提交提供更好
210
247
提交没有合并到最新版本而造成已修复问题在新版本中重现。
211
248
212
249
Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪最新的发行版,
213
- 当确定里程碑tag v1.6.4 为最新发行版时,在 maint
250
+ 当确定里程碑tag v1.6.4 为最新发行版时,在 maint
214
251
分支执行如下命令以切换到最新发行版:
215
252
216
253
$ git checkout maint
0 commit comments