当前位置:文档之家› 项目svn版本控制中的分支策略

项目svn版本控制中的分支策略

项目svn版本控制中的分支策略
项目svn版本控制中的分支策略

[原创]项目svn版本控制中的分支策略

[原创]项目svn版本控制中的分支策略分类:

tool

svn

2010-06-10 23:14

2822人阅读

评论(0)

收藏

举报

[原创]项目svn版本控制中的分支策略

by AKara 2010-06-07 @ https://www.doczj.com/doc/d71120531.html,/akara @ akarachen(at)https://www.doczj.com/doc/d71120531.html, @https://www.doczj.com/doc/d71120531.html,/akaras 结合项目运营的一些体会,浅谈一下项目中经常用到的分支策略。从一个很旧的PDF <<Essential CVS>> 上发现了一些篇章,回头一读发现

多年前精简的原则阐述放到现在来说,仍有非常好的指导意义,基本涵盖我

打算要总结的内容了,干脆翻译一遍它。虽然用的是svn,

但是应该和cvs本质

上是相同的理念~

---------------------------------------------------------------------

(翻译仓促,如需转载请先联系:https://www.doczj.com/doc/d71120531.html,/akara / akaras@https://www.doczj.com/doc/d71120531.html,)4.4 Branching Strategies

本章将讲述分支策略中的基本原则以及两种主要的分支

原则。

并给予一些关于何时/为何你需要在一个项目中开辟分支的解答。4.4.1 Branching Philosophies

关于分支的经验法则是:保持开发的主线位于trunk(主干)上;而其他的一切,

branch(分支)。问题在于如何界定哪些是开发的主线。trunk 应该只包含稳定

的代码还是也可容忍不稳定的代码?是否在每个release被测试前都应该分支?

新功能应该在trunk上开发还是在一个branch上开发?上面这些疑问都源于我们对'开发的主线'有两种不同的定义。这两种定义引出

了两种截然不同的分支原则,术语上称basically stable和basically unstable。4.4.1.1 Basically stable

顾名思义这个分支原则主导思想是trunk只包含稳定的随

时可发布的代码。

branches则用于开发新功能/修正bug/发布前的QA控制/重构/实验性质功能试点。

该原则下最严格的遵行方式为:任何未经严格QA控制的代码都不能merge回trunk。

这样便能保证任何时刻都可以从trunk上分出一个release candidate(rc),

它只需要通过少量的QA控制流程便能进入正式发布。不那么严格的遵行方式则允许通过开发者的unit-testing的代码merge回trunk。

这种稍微宽松的方式则需要通过全套的QA控制监督才能进入正式发布流程。Basically stable原则下有一些优点:* 任何时刻可以分出一个release。并配以简单QA控制就加以发布。

* 因为trunk只包含稳定的代码,并且变动的节奏很慢;

所以你可以在branch上作大量的实验性改动,而不用担心merge回trunk时

会和别人的工作掺杂在一起而导致bug。

而这个原则下最大的缺点是:merge通常由QA测试员来进行而不是理解代码语义

的编写者来进行。另一个缺点是:在从一个branch往trunk merge完成后,trunk

上的改动相对于这个branch被分出去的那个版本来说,可能是巨大的。当然这两个

问题都可以通过使开发者周期性地merge回trunk而得到一定程度上的减轻;或者

遵行更为宽松的merge要求。4.4.1.2 Basically unstable Basically unstable原则下,要求trunk包含最新的代码,不管它的稳定性如何;

而用于release candidate的版本则应该开辟一个分支来交付。该原则下最严格的遵行方式为:所有开发都在trunk 上进行,只有rc,

bugfix branch,release等性质的事件才会开辟branch。稍为宽松的遵行方式为则允许使用branch来进行实验性编码,重构,以及其他

特殊用途的代码开发。而往trunk merge则通常由相应branch的负责者来完成。

Basically unstable原则的优点是merge是个不常发生的事情,而且是个相对

容易完成的事情———因为是由熟悉branch代码的负责者来完成merge。而它的缺点显然是trunk包含了不稳定的

代码,可能是实验性功能,甚至连

编译都不能通过的代码。经常进行tagging可以减少这个缺点带来的影响,

所以每次对每次实验功能和重构等进行tag操作是个好习惯。更宽松的的遵行

方式是将那些bug倾向极大的代码从trunk上branch出去,为随时从trunk准备

一个release提供更好的环境。4.4.2 Branch Styles

CVS包含创建和使用branch的一些方法,但是它不强迫使用者必须使用某种

技巧来使用。本章介绍几种使用branch的风格。

本章中的"long branch"术语指的是正在使用的branch或

者经过多次merge

回trunk的已经废弃的branch。而'short branch'术语是指那些只merge一次

回trunk便废弃的branch。当然,CVS中的'废弃'并不等

于不存在;CVS允许任意时刻又重新开始使用任何

一个branch。结束或废弃一个branch只是简单地告诉所有开发者:不要再使用

它了。4.4.2.1 Long branch, merging to branch

从trunk上往的一个正在开发的branch中经常merge内

容的做法对于某些情形

非常有用:trunk不希望受到branch的改动影响,但是branch 希望接收trunk上

的有用的改进部分。镜像站点就是这种情形。图4-6 描述了这个做法:

Branch ______________________

/ ↑merge ↑merge

↑merge

Trunk ——————————————————————>

图4-6 从trunk上往branch多次merge 内容4.4.2.2 Long branch, merging to trunk

从正在开发的branch往trunk中经常merge内容的做法对于如下情形非常有用:

branch不希望受到trunk上改动的影响,但是trunk希望融合branch上的改进。

在一个branch正在处于测试期或正处于发布前期时;这个做法会有很好的效果。

处于测试中的项目可以采取本做法,将branch上已经测试的修改merge回trunk中。

图4-7描述了这个做法:Branch ______________________

/ ↓merge ↓merge

↓merge

Trunk ——————————————————————>

图4-7 从branch上往trunk多次merge 内容4.4.2.3 Long branch, merging both trunk and branch Long branch和trunk之间也可用互相merge的做法来保证双方的改动都同时

双方得到融合。如果开发者在branch上进行着不稳定的编码工作,那可以在

每个里程碑完成时往trunk中merge,而branch也可以随时准备接受trunk上的

改动同步。当你一步步地往一些成熟的代码添加新功能的时候,这个方法可以

很好地进行版本管理。图4-8 描述了这个做法:

Branch ______________________

/ ↑merge ↓merge

↑merge

Trunk

——————————————————————>

图4-8 trunk和branch互相merge4.4.2.4 Short branches

为一个简单功能修改而开辟的独立branch我们叫它short branch。如果你希望

增加一个独立功能/ 编写实验性代码/ 准备发布版本,那这就是很理想的做法。显然可以用系列的short branches 来模拟一个long branch在branch和trunk

间相互merge的情况。通过这个方法,就避免了先从long branch中merge改动

回trunk,然后又要从trunk往long branch中merge更改的麻烦——取而代之的是

你只需从short branch中往trunk merge,然后再从trunk 开辟一个新的short branch

继续如此循环,直至达到目标开发量。这种方法很适合在trunk和branch都将有

重大的变动的情形。图4-9 描述了这个做法:

Branch _____ Branch_____ Branch_____

/ ↓merge /

↓merge / ↓merge

Trunk

———————————————————————>

图4-9 short branches

4.4.2.5 Nested branches

CVS允许从branch上开辟branch。子branch将视父branch为trunk。上面讨论过

的trunk和branch之间的原则可以一样地继续应用。嵌套branches在将CVS用作

配置管理系统的时候非常有用。同时需要注意,减少嵌套的复杂度总能减少混淆。

如果你正在一个branch写一个新功能集合,而又需要在部分功能交付测试时继续

你的开发,你便应该在这个branch之上再开辟一个新的branch用来交付测试。

见图4-10 描述:

Branch2.3.2.2.2___2.3.2.2.2.1___2.3.2.2.2___

/

Branch

2.3.2___2.3.2.1___2.3.2.2___2.3.2.3___2.3.2.4___

/ /

/

/___2.3.2.3.2.1__2.3.2.3.2.2__

/

Trunk

———2.2—————2.3—————2.4——————2.5——————>

图4-10 Nested branches 4.4.3 Branch Polices

有一些一贯的原则可以帮助你利用分支来加强项目中的版本管理。脱离这些原则,

可能会让你在一团糟的分支关系中迷失方向。

拥有和遵守这些原则同时也帮助你将merge变得更加简单易操作。减低merge的成本

需要branch和trunk上的开发者进行足够的交流。

让这些原则在你的项目和团队中成为规章吧。下面是我和同事都觉得有用的

一些原则:

* 对项目有总体的(版本管理)设计。

* 开辟每个branch前确定它的目标;并尽量减少项目中有效的branch。

* 尽量降低branch方案的复杂度。CVS允许嵌套分支,但嵌套分支这种复杂情况

很少为项目带来好处:)

* 使用一致的branch命名规则来表达分支的用途。

* 注意branch和trunk的差别同步;好的设计和交流会减少这种问题发生的可能性。

一个例子是:当一位开发者改变了某函数的参数个数(更糟糕的是,参数的顺序);

但其他开发者仍未得到通知,而且没有merge,仍在用旧的参数方式来调用函数。

* 尽量避免在CVS中提交二进制文件,以便CVS进行自动的文件merge操作。

* 经常merge。显然,改动越少,merge越简单。

* 标记好每个merge点的信息,以便避免对同一个改动重复merge。

* 在trunk上的每个branch点/merge前/merge后做好标记信息;方便随时取回

某个trunk状态下的信息。

* 使用一致的branch标记信息规则。

(翻译仓促,如需转载请先联系:https://www.doczj.com/doc/d71120531.html,/akara / akaras@https://www.doczj.com/doc/d71120531.html,)

--------------------------------------------------------------------- 说

回项目中的分支策略。

假设每次运营维护期大概一周。下面以周为最短的分支周期。

我们采取的是Basically unstable 原则,一般的最新代码在trunk上开发。

每次对外发布则开辟rc branch提交QC。然后该branch 进入为期一周的buf fix mode。

用时一周左右的的改动一般用short branch的形式进行。改动完后一次性往回merge。

long branch则只用于超过两周的功能开发。每次merge back操作由branch负责人进行。每次rc branch通过QC full tested 后将直接当作release;

freeze后的二进制档将自动提交到freeze svn仓库作为一个可回滚的发布版本,

并由SA作为最新发布的根据。希望有更多的项目运营经验的朋友交流讨论。

一个SVN管理多个资料库时的用户权限配置

作为一个配置管理员,需要管理用户的权限,本文主要介绍了使用Subversion的授权文件“authz-db”,同时为了叙述的清晰,我首先澄清一些概念。 认证(Authentication)和授权(Authorization) 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份,最常见的方式就是使用用户名和密码,授权就是判断用户是否具备某种操作的权限,在Subversion里提供了“authz-db”文件,实现了以路径为基础的授权,也就是判断用户是否有操作对应路径的权限。svnserve下的配置文件 因为本文是以svnserve为例的,所以先介绍一下版本库目录的结构: D:\SVNROOT\PROJECT1 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks 其中conf下面有三个文件: authz passwd svnserve.conf 其中的“svnserve.conf”是这个版本库的配置文件,当使用svnserve时,这个配置文件决定了使用什么认证和授权文件: password-db = passwd authz-db = authz 上面的配置说明使用“svnserve.conf”同目录的passwd和authz,其中的password-db指定了用户密码文件,authz-db是我们的授权文件,也就是我们本文主要介绍的文件。 基于svnserve的版本库文件布局 使用svnserve时,为了管理的方便,应该使用相同的认证和授权文件,所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录: D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db

SVN管理员使用指南

SVN 管理员使用指南

目录 1Subversion简介 (1) 1.1Subversion简介 (1) 1.2Subversion架构 (2) 1.3Subversion组件 (3) 1.4Subversion基本流程 (3) 2安装SVN 服务 (4) 2.1安装SVN和TortoiseSVN (4) 2.2创建SVN资源库 (4) 2.3创建SVNserver服务 (5) 2.4运行SVNserver服务 (6) 3用户及权限管理 (6) 3.1用户管理 (7) 3.2权限管理 (7) 4SVN基本使用 (9) 4.1导入/导出(import/export) (9) 4.2初始化检出(checkout) (10) 4.3更新修改(update) (10) 4.4查看日志信息(show log) (10) 4.5取消修改(revert) (10) 4.6提交修改(commit) (10) 4.7合并信息(merge) (10) 4.8创建/删除/重命名 (10) 4.9加锁/释放锁(get/release lock) (10) 4.10添加、删除、重命名(add、delete、rename) (10) 4.11拷贝(copy) (13) 4.12查看修改信息(check for modifications) (13) 4.13分支/标记(branch/tag) (13)

4.14创建并应用补丁(create/apply patch) (15) 4.15备份/恢复资源库 (17) 4.16删除资源库 (19) 4.17版本(revision)关键字 (19) 4.18统计信息(statistics) (20) 4.19禁用密码缓存 (21) 5TortoiseSVN设置 (21) 5.1常规设置(General) (23) 5.2图标叠加(Icon overlays) (27) 5.3网络设置(network) (29) 5.4日志缓存设置(log caching) (30) 5.5钩子脚本设置(Hook Scripts) (32) 5.6外部程序设置(external programs) (32) 6TortoiseSVN基本命令 (37) 6.1Svn子命令 (37) 6.2Svnadmin (38) 6.2.1Svnadmin Switches (39) 6.2.2Svnadmin Subcommands (39) 6.3Svnlook (40) 6.3.1Svnlook选项 (40) 6.3.2Svnlook (41) 6.4Svnserve (41) 6.4.1Svnserve选项 (41) 6.5Svnversion (42) 6.5.1Svnversion选项 (42)

SVN权限控制解析

SVN权限控制解析 作为一个配置管理员,需要管理用户的权限,本文主要介绍了如何使用Subversion的授权文件“authz-db”,同时为了叙述的清晰,我首先澄清一些概念。 1、认证(Authentication)和授权(Authorization) 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份,最常见的方式就是使用用户名和密码,授权就是判断用户是否具备某种操作的权限,在Subversion里提供了“authz-db”文件,实现了以路径为基础的授权,也就是判断用户是否有操作对应路径的权限,在Subversion 1.3之后,svnserve和Apache一样都可以使用“authz-db”文件。 2、svnserve下的配置文件 因为本文是以svnserve为例的,所以先介绍一下版本库目录的结构: 其中conf下面有三个文件: 其中的“svnserve.conf”是这个版本库的配置文件,当使用svnserve时,

上面的配置说明: 1、匿名用户的权限为none(可以为none、read、write) 2、认证用户的权限为write(可以为none、read、write。SVN的权限 认证方式是基于此处的设置和anthz授权文件中的设置,两者都满足 (&方式)才成立,即 read&read=read,read&write=read,write&write=write,所以 此处应把认证用户的权限设置为write,否则authz文件中关于写权 限的设置都会无效的 3、使用了“svnserve.conf”同目录的passwd和authz,其中的 password-db指定了用户密码文件,authz-db是我们的授权文件, 也就是我们本文主要介绍的文件。 4、realm为“My First Repository”,这个值作为客户端保存服务器端 信息(如用户和密码)的唯一识别符 注意:使用Apache作为服务器时,根本就不会参考“svnserve.conf”文件的内容,而是会参考Apache的配置。 3、基于svnserve的版本库文件布局 使用svnserve时,为了管理的方便,应该使用相同的认证和授权文件,所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录:

实现精细的目录访问权限控制 svn

================ Subversion之路 ================ ---------------------------- 实现精细的目录访问权限控制 ---------------------------- :作者: 郑新星 :联系: zhengxinxing gmail com :状态: 正稿 :版本: 1.0 :修订: $Id: The.Road.to.Subversion_authz.rst 1749 2006-12-05 08:05:59Z zhengxinxing $ :版权: 作者保留对本文的一切修改、发布等权力。任何人想要转载本文部分或全部内容时,必须保留包括作者、联系、状态、版本、修订、版权,共六项信息,并给出出处。对本文的参考引用,则不受限制。 :关键词: Subversion 目录访问权限 :献辞: 仅以本文,献给中国广大的自由软件爱好者们 :摘要: 本文从一个实际的例子入手,介绍了如何利用Subversion 自带的目录管理功能,来实现对项目目录的精细访问权限的控制。同时描述了在配置的过程中,需要注意的一些地方,如对中文的处理等。 .. section-numbering:: .. contents:: 目录 :backlinks: top 前言 ==== Subversion 权限简介 ------------------- 在Subversion 的使用当中,存在“认证”、“授权”两个概念。认证,即authentication,是指用户名与密码的认证。授权,即authorization ,是指某用户对某个目录是否具备读、写权限的一种审核。这两者配合作用,就组成了Subversion 的整个帐户管理体系。 在实际的工作当中,我们有时候会遇见需要控制项目目录的访问权限的情况,比如说对项目的一些关键模块进行限制,仅允许少数授权人士才可以修改等。由于项目的目录本身就是作为版本库的一个部分被Subversion 所收管,所以我们无法利用操作系统的帐户权限体系,来实现授权控制。因此,这个问题就只有让svn自己来解决了。

svn用户权限管理

SVN用户权限管理讲解 /***********************************************************/ //SVNSubversion 用户权限管理//资料来源:网络、总结//2010年7月20日 /***********************************************************/ 基本的操作:以我创建的Svn工程为例子来讲解SVN权 /***********************************************************/ //SVNSubversion 用户权限管理 //资料来源:网络、总结 //2010年7月20日 /***********************************************************/ 基本的操作: 以我创建的Svn工程为例子来讲解SVN权限管理的配置 仓库创建路径:D:\SVNLibrary >>>取消匿名登陆: 打开文件D:\SVNLibrary\conf\svnserve.conf 找到:###anon-access = read 将前面的注释去掉,并将read 改为:none 即使:anoe-access=none 表示匿名登陆下的用户权限为空。即:系统不支持匿名登陆 说明: auth-access = write #通过验证的用户可以读和写 auno-access = read #匿名登陆下可以只读文件,即:文件修改后无法提交到服务器 password-db =password #用户保存文件的名称 authz-db =authz #权限管理文件这个是非常重要的,如果我们要对整个工程的文件进行权限分配的时候,就必须将这个行文件前面注释掉,否咋即使我们在权限配置文件里面进行再多的配置都是无效的。这点我已经犯错了。 然后我们在authz 文件下面进行权限的分配 在权限分配的时候要注意的问题: >>>权限分配时,应遵守从根目录到子目录、从设置最广泛权限到最精细权限、从只读权限到读写权限设置原则,即从根目录开始设置最广泛的访问权限,然后逐步设置下属子目录的访问权限。提示:目录的访问权限既可以分配给组,也可以分配指定用户。 >>>对某个用户,如果只赋给他某个目录的权限,但对上级目录没有赋给,则他不能有上级目录的任何权限 例如某个用户有:/repository/project1的r权,而没有/repository的r权 >>>对于所有的目录,都优先处理设置在这个目录上的权限设置。 例如sai用户: [/repository] sai = rw 对于repository目录,他有rw的权限。 [/repository/project1] sai = r 对于repository下的project1目录,他只有r权限。

svnserve权限设置

Svnserve单项目权限设置 目录 Svnserve单项目权限设置 (1) 目录 (1) 前言 (1) 一项目结构 (2) 二建立版本库 (4) 三配置权限 (4) 四导入项目版本库 (9) 五启动svnserve (13) 六将svnserve设置为系统服务 (14) 1,安装svnservice (14) 2,删除服务 (15) 3,配置服务是自动启动 (15) 致谢 (16) 前言 目前网络上有很多的关于svn安装与权限设置的文章(基于SVN

自带的svnserve),但是如果您像我一样按照那些文章来进行我们的subversion的安装和设置会发现有很多问题,可以说每篇文章都有这样或那样的错误。或者断章取义,或者根本就没亲自验证就写出来,贴到网络上,然后又有很多人直接转帖到自己的博客,空间中。这就造成了网络上大量的权限设置文章根本是无法正确设置权限的。在学习那些“权限设置精细”文章的过程中,给我们的身心都造成了严重的伤害。至少给我幼小的心灵造成了创伤。每次上网搜到一篇文章都觉得这次总该可以了吧,结果全盘照抄了,还是不行。累的我真的想放弃了。还好后来有一篇文章给了我启发,那是我找过的唯一一篇有我需要的细节的文章。 这篇文章是专门写给像我一样的菜鸟,而又因为这样或那样的原因需要了解svnserve权限设置的人,也就是“侏儒”。如果您对windows 比较了解,也就是身高在1.5米以上的,偏矮的人,正常人,比较高的人,非常高的人,或者像姚明一样的巨人的话,那你会发现此篇文章极尽啰嗦,繁琐。对此我深表歉意! 一项目结构 亿联网络技术有限公司是一家专注于网络通讯产品的研发及销售的高科技企业。目前,公司主要致力于V oIP网关、V oIP终端、WIFI 和IP-PBX等网络通讯产品的开发、生产和销售。产品以出口为导向,95%产品远销英国、德国、美国、韩国等50多个国家与地区,拥有一批诸如Nortel、FranceTelecom, Skype等优质合作伙伴

SVN权限控制

权限配置 作为一个配置管理员,需要管理用户的权限,本文主要介绍了使用Subversion的授权文件“authz-db”,同时为了叙述的清晰,我首先澄清一些概念。 1. 认证(Authentication)和授权(Authorization) 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份,最常见的方式就是使用用户名和密码,授权就是判断用户是否具备某种操作的权限,在Subversion里提供了“authz-db”文件,实现了以路径为基础的授权,也就是判断用户是否有操作对应路径的权限。 2. svnserve下的配置文件 因为本文是以svnserve为例的,所以先介绍一下版本库目录的结构: D:\SVNROOT\PROJECT1 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks 其中conf下面有三个文件: authz passwd svnserve.conf

其中的“svnserve.conf”是这个版本库的配置文件,当使用svnserve时,这个配置文件决定了使用什么认证和授权文件: password-db = passwd authz-db = authz 上面的配置说明使用“svnserve.conf”同目录的passwd和authz,其中的password-db指定了用户密码文件,authz-db是我们的授权文件,也就是我们本文主要介绍的文件。 3. 基于svnserve的版本库文件布局 使用svnserve时,为了管理的方便,应该使用相同的认证和授权文件,所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录: D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db │ │ ├─revprops │ │ ├─revs │ │ └─transactions │ ├─hooks │ └─locks └─project2 ├─conf ├─dav

SVN权限详解

【转贴】Subversion权限详解 1 背景假设 厦门央瞬公司是一家电子元器件设备供应商,其中有个ARM部门,专门负责ARM 芯片的方案设计、销售,并在北京、上海各设立了一个办事处。对于工作日志,原先采用邮件方式发给经理,但是这种方式有个缺点,那就是不具备连续性,要看以前的日志必须一封一封邮件去查看,很麻烦。于是就想到利用 Subversion,让员工在自己电脑上编辑日志,然后利用svn传送回来,既方便员工自己编写日志,又方便对日志的归档处理,而且提交日志的时候只需要执行一下 svn update 即可,比发送邮件还要简单的多。 ?svn服务器相关信息 o服务器地址:192.168.0.1 o服务器OS:MS Windows 2000 Server Edition 中文版 o代码库本地目录:D:\svn\arm ?arm部门文档的目录结构如下: ?arm 部门名称 ?├─diary 工作日志目录 ?│ ├─headquarters 总部工作日志目录 ?│ ├─beijing 北京办日志目录 ?│ └─shanghai 上海办日志目录 ?├─ref 公司公共文件参考目录 ?└─temp 临时文件目录 ?人员情况 o morson,公司总经理,其实他不必亲自看任何东西,就连部门经理们的每周总结都不一定看。但是为了表示对他的尊敬,以及满足一下他的权力欲,还 是给他开放了“阅读所有文档”的权限 o michael,arm事业部的部门经理,没事的时候喜欢弄点儿新技术,用svn来管理日志,就是他相处来的主意 o scofield,北京办人员,老员工,为人油滑难管 o lincon,上海办人员,老员工,大老实人一个 o linda,总部协调员、秘书,文笔不错,长得也不错 o rory,单片机技术员,技术支持 ?访问权限需求分析 o允许总经理读取所有文件 o除部门经理外,所有其他人员,均只能看到本办事处人员工作日志 o不允许匿名访问 o ref目录只允许经理和秘书写,对其他人只读 o temp目录人人都可以写

SVN权限详解

【转贴】Subversion权限详解 1背景假设 厦门央瞬公司是一家电子元器件设备供应商,其中有个ARM部门,专门负责ARM芯片的方案设计、销售,并在北京、上海各设立了一个办事处。对于工作日志,原先采用邮件方式发给经理,但是这种方式有个缺点,那就是不具备连续性,要看以前的日志必须一封邮件去查看,很麻烦。于是就想到利用Subversion,让员工在自己电脑上编辑日志,然后利用svn传送回来,既方便员工自己编写日志,又方便对日志的归档处理,而且提交日志的时候只需要执行一下svnupdate即可,比发送邮件还要简单的多。 svn服务器相关信息 o服务器地址: 192.168. 0.1 o服务器OS: MS Windows 2000 Server Edition中文版 o代码库本地目录: D: \svn\arm arm部门文档的目录结构如下: arm部门名称 ├─diary 工作日志目录 │ ├─headquarters 总部工作日志目录 │ ├─beijing 北京办日志目录

│ └─shanghai 上海办日志目录 ├─ref 公司公共文件参考目录 └─temp 临时文件目录 人员情况 omorson,公司总经理,其实他不必亲自看任何东西,就连部门经理们的每周总结都不一定看。但是为了表示对他的尊敬,以及满足一下他的权力欲,还是给他开放了“阅读所有文档”的权限 omichael,arm事业部的部门经理,没事的时候喜欢弄点儿新技术,用svn 来管理日志,就是他相处来的主意 oscofield,北京办人员,老员工,为人油滑难管 olincon,上海办人员,老员工,大老实人一个 olinda,总部协调员、秘书,文笔不错,长得也不错 ory,单片机技术员,技术支持 访问权限需求分析 o允许总经理读取所有文件 o除部门经理外,所有其他人员,均只能看到本办事处人员工作日志o不允许匿名访问 oref目录只允许经理和秘书写,对其他人只读 otemp目录人人都可以写 2建立代码库 在服务器D: \svn目录下,建立arm代码库,命令如下:

SVN超级管理员使用指南

SVN超级管理员使用指南 目录 1登陆SVN后台管理 (2) 2首页菜单介绍 (2) 3超级管理员主要管理功能 (3) 4操作详细介绍 (3) 4.1用户管理 (3) 4.1.1邀请用户 (3) 4.1.2手动添加用户 (4) 4.1.3编辑用户 (5) 4.1.4删除用户 (6) 4.2用户组管理 (8) 4.2.1创建用户组 (8) 4.2.2删除用户组 (9) 4.2.3编辑用户组 (10) 4.3一级目录管理 (12) 4.3.1创建一级目录 (12) 4.3.2删除一级目录 (13) 4.3.3编辑一级目录 (14) 5场景示例1: (16)

1登陆SVN后台管理 1、输入:http://xy.svn/svnman/出现SVN后台管理登陆界面: 2、选择login,并输入用户名和密码,点击login按钮 3、登陆成功 2首页菜单介绍 左图为超级管理员登入时的菜单显示 “User Admin”:用户管理; “Group Admin”:用户组管理; “Repository Admin”:一级目录管理; “Logout”:登出;

3超级管理员主要管理功能 用户管理:邀请、增加、编辑、删除用户账号 用户组管理:新建、删除用户组、编辑用户组成员,用户组是为了权限设置方便,将多个具有相同或相似权限的用户设为一个用户组。 一级目录管理:建立一级目录,并设置该目录的管理员。 4操作详细介绍 4.1用户管理 点击首页菜单的“User Admin”进入用户管理界面,如下图 4.1.1邀请用户 建议使用邀请用户功能添加新用户,新用户可以通过邀请邮件中的链接地址进入系统自己注册帐号和密码。节约管理时间并保证了帐号安全。 点击第一个“Invite”按钮进入邀请用户界面,如下图

visualSVN_server权限配置使用说明

VisualSVNserver使用配置说明 一、VisualSVN server的配置简介 VisualSVN Server适用于你的团队在Windows平台上使用,可以用来安装、配置和管理Subversion Server,其中包括了Subversion和一个管理控制台。你可以使用Subversion client 连接到VisualSVN Server ,也可以用浏览器来快速浏览内容. 而且它可以帮助你将Subversion整合进Visual Studio. 其官网下载地址:https://www.doczj.com/doc/d71120531.html,/server 二、VisualSVN server的安装 1、双击下载好的安装软件,出现下图 点击上图Next,进入下图所示: 点击复选框,点击Next,进入下图:

设置如上图所示,进入下图: 这里要求你填入VisualSVN Server的安装位置,以及选择服务器端口和连接协议,,在大多数情况下可以使用默认值。点击Next完成VisualSVN server的安装。

三、V isualSVN server的使用 3.1 管理控制台 VisualSVN Server 提供了一个简单和直观的标准MMC snap-in管理控制台。 你可以通过“开始菜单→所有程序”或者通过标准MMC来访问它。 通过管理控制台,你可以很方便地创建新版本库或浏览已经存在的库。同样,你可以管理对版本库的访问权限。 3.2 创建版本库 可通过右键Repositories→Create New Repositories来创建,当创建一个新的版本库时,

基于web平台的SVN权限管理方法及其设备的制作技术

图片简介: 本技术提供一种基于web平台的SVN权限管理方法及其装置,所述方法包括:利用web平台建立SVN权限管理界面,所述权限管理界面中包括组别、人员和文件目录;在所述权限管理界面中设置文件目录下的访问权限;在所述权限管理界面中根据所述访问权限对所述人员划分组别;根据所述访问权限和所述分组生成独立于SVN的外部权限配置文件;将所述外部权限配置文件推送至SVN服务器。本技术无需在SVN内部的配置文件中直接修改文本,防止由于编辑错误导致权限管理混乱并且难以查找原因的缺陷。本技术通过外部界面化的设置使得权限管理操作更加灵活便利,从而大大提高SVN版本管理的工作效率。 技术要求 1.一种基于web平台的SVN权限管理方法,其特征在于,包括: 利用web平台建立SVN权限管理界面,所述权限管理界面中包括组别、人员和文件目录;在所述权限管理界面中设置文件目录下的访问权限; 在所述权限管理界面中根据所述访问权限对所述人员划分组别; 根据所述访问权限和所述组别生成独立于SVN的外部权限配置文件;

将所述外部权限配置文件推送至SVN服务器。 2.根据权利要求1所述的SVN权限管理方法,其特征在于,所述访问权限的设置规则为:根据不同职责确定所述人员对文件目录下的文件项的执行权力;所述访问权限包括:对文件目录下的文件项具有只读权限,对文件目录下的文件项具有修改权限和对文件目录下的文件项具有删除权限。 3.根据权利要求2所述的SVN权限管理方法,其特征在于,所述根据所述访问权限对所述人员划分组别包括:将具有只读权限的人员划分为第一组别,将具有修改权限的人员划分为第二组别,以及将具有删除权限的人员划分为第三组别。 4.根据权利要求2所述的SVN权限管理方法,其特征在于,具有多个权限的人员同时被划分到多个组别。 5.一种基于web平台的SVN权限管理装置,其特征在于,包括: 界面建立模块,适用于利用web平台建立SVN权限管理界面,所述权限管理界面中包括组别、人员和文件目录; 权限设置模块,适用于在所述权限管理界面中设置文件目录下的访问权限; 分组模块,适用于在所述权限管理界面中根据所述访问权限对所述人员划分组别; 配置文件模块,适用于根据所述访问权限和所述分组生成独立于SVN的外部权限配置文件; 推送模块,适用于将所述外部权限配置文件推送至SVN服务器。 6.根据权利要求5所述的SVN权限管理装置,其特征在于,所述访问权限的设置规则为:根据不同职责确定所述人员对文件目录下的文件项的执行权力;所述访问权限包括:对文件目录下的文件项具有只读权限,对文件目录下的文件项具有修改权限和对文件目录下的文件项具有删除权限。 7.根据权利要求6所述的SVN权限管理装置,其特征在于,所述分组模块包括: 第一分组模块,适用于将具有只读权限的人员划分为第一组别;

SVN分级授权工具部署手册--Windows用户认证--Visual SVN 权限

技术文档莫模板 技术支持文档系列 SVN分级授权部署手册 --Windows用户认证 (文档编号:MCTD-P2*******-I20140001-V0101) 此工具及文档为闲暇之作,疏漏之处请理解。 艾维工作室 IIVII STUDIO 二〇一四年十月﹒成都

文档说明 修订记录

目录 第一章概述 (4) 第二章安装部署 (5) 2.1Windows操作系统 (5) 2.2SVN服务软件安装 (5) 2.3SVN分级授权工具安装 (11) 2.3.1 安装C++运行库 (11) 2.3.2 部署数据库、COM+和WebSerivce (12) 2.3.3 安装同步服务 (21) 2.3.4 更改登录认证方式 (23) 2.3.5 SVN分级授权参数配置 (25) 2.4发布分级授权工具 (25) 第三章基本操作 (28) 3.1用户批量导入 (28) 3.2超级管理员SVNADMIN (29) 3.3SVN工具权限管理 (29) 3.4管理SVN用户 (30) 3.5管理员重置用户的SVN密码 (34) 3.6用户修改自己的SVN密码 (34) 3.7创建SVN仓库 (35) 3.8SVN仓库权限管理 (38) 3.9获取SVN存取的URL地址 (41) 第四章进一步阅读 (42)

第一章概述 当VisualSVN 2.7采用Windows用户认证或Windows域认证时,可以使用SVN分级授权工具对VisualSVN的授权功能进行扩展,实现SVN库的创建、分库的分级授权、SVN用户密码修改等。本手册主要描述Windows用户认证的配置方法,关于采用Windows域认证的配置方法请参考《SVN分级授权工具部署手册--Windows域认证》。

svn服务器端配置库创建及配置方法

SVN服务器端配置库创建(Express版) 1创建SVN配置库目录 在某一路径下,点击鼠标右键-新建-文件夹,创建一个文件夹,并修改目录名(如MySVN, 在本文档中称之为SVN配置库)。右键点击该目录,选择TortoiseSVN-Create repository here。 (备注:"repository ”是英文"储藏室”的意思) 匚回 知记JT3FCD) QQMusic QQMusic轿啟肌列叱 v便用撅廉毫扫摘 共孚和虽全何”. ^]SVN CbKhwtH? ^TortciseSVN ?Repo-browser 番淆姐旺臧件回“ 1-1Create repository 创建 SVN 配置库 2对SVN配置文件进行配置 SVN配置库目录建立后,需要对配置文件进行配置。进入配置库目录下的conf目录, 其中有authz、passwd、svnserve三个文件,anthz配置用户权限、passwd配置用户名与密码、svnserve 即为配置文件的配置文件。在这三种文件中“ #”为注释行起始符号。另外需要注 意的是,配置语句的每一行不能有多余的空格。 2.1 svnserve文件的配置 将整个文件中的内容替换为以下内容即可。 [ge neral] anon-access = read auth-access = write

password-db = passwd II定义passwd文件为用户名-密码数据库 authz-db = authz II定义authz文件为权限管理数据库 2.2 passwd文件配置 passwd文件主要用于设置用户名与密码,其语法格式为“用户名=密码”。如添加用 户名为user,密码为pwd的用户,则可以使用如下方法实现: [users] user = pwd II定义用户 user,其密码为 pwd 2.3 authz文件配置 authz文件主要用于设置用户所属群组,配置用户权限及群组权限。群组信息在[groups] 标签下配置;某个目录的读写权限则在[某路径]标签下配置,r表示可读权限,w表示可写 权限,rw表示可读可写权限。假设passwd文件中定义了 A、B C、D四个用户,下面将进 行一些配置并对这些配置的含义进行说明。 [groups] groupA = A,B II定义群组groupA,它具有两个用户 A、B groupB = C,D II定义群组groupB,它具有两个用户 C、D [I] * = r II在根目录所有用户有只读权限 A = rw II在根目录用户 A具有读写权限 @groupB = rw II在根目录群组 groupB具有读写权限 [I目录A] @ groupA = rw II在目录 A群组groupA具有读写权限 C = w II在目录A用户C具有写权限 3开启SVN服务程序 一个SVN配置库的配置过程至此就结束了,下面需要开启一个SVN服务,并以刚建立 的SVN配置库MySVN作为配置库,才能使用。下面使用彭斌开发的 myswapper配置工具进行配置,该工具可以简化配置时所输入的命令行,而使用图形界面进行配置。配置前将myswapper工具复制到某一

Visual SVN权限配置

Visual SVN的权限配置是在SVN_ROOT根目录下面的三个文件内 1)authz:Visual SVN账户权限配置; 2)authz-windows:如果使用Windows域账户,权限配置在此文件配置; 3)htpasswd:账户名及密码; 注:SVN正常是在每个版本库内都有单独的权限配置文件,如project、office、public等目录内都会有单独的权限配置文件,而VisualSVN将所有版本库的权限配置集中到了根目录下面。相对配置更加简单。 我们目前使用以下两种方式进行权限的设置: 1、Visual SVN图形化控制界面 在该界面可以实现如下功能: 1)新建用户user; 2)新建组Group并添加用户user; 3)配置用户user或组group对产品库如Project、Office、Public的访问权限; 2、手动修改authz文件进行权限配置,但是需要注意以下几点: 1)authz文件为“UTF-8 无BOM”格式,在使用记事本打开修改保存之后需要注意避免修改格式。建议使用UltraEdit进行修改并且保存为“UTF-8 无BOM”格式。 2)authz文件目前测试发现将其中Windows2008中Copy到XP系统内本身就会发生变化,如38k大小的文件会变成48k,在将xp内的authz不做任何修改copy会SVN_ROOT 中时,VisualSVN打开时依然会提示“……\authz:1: Section header expected”错误。 由此可见在Copy到XP时文件已经发生了修改。具体原因不详,目前直接在windows2008 server当中进行修订并保存为“UTF-8无BOM”格式,验证OK。验证Copy到windows7 64bits中没有文件大小无变化。 王新2014年5月4日

SVN配置权限

Subversion精细化权限配置 版本历史 版本/状态作者变更理由/内容生效日期备注 1.1 孙炬2010-4-22 引言 目录 1. 准备工作 (1) 1.1. 新建代码库 (1) 1.2. 配置代码库 (1) 2. 配置详解 (3) 2.1. Passwd.conf (3) 2.2. authz.conf (4) 3. 补充重要说明 (6) 3.1. 对中文目录的支持 (6) 1.准备工作 1.1. 新建代码库 svnadmin create F:\server\svn\root 1.2. 配置代码库 进入conf目录

删除掉authz和passwd这两个文件(是默认的配置,没什么用) 打开svnserve.conf找到[general],把[general]到# realm = My First Repository这一行之前的内容全部删除掉,在这两行之间加入 password-db = ../../passwd.conf anon-access = none auth-access = write authz-db = ../../authz.conf 整个文件的配置如下: ### This file controls the configuration of the svnserve daemon, if you ### use it to allow access to this repository. (If you only allow ### access through http: and/or file: URLs, then this file is ### irrelevant.) ### Visit https://www.doczj.com/doc/d71120531.html,/ for more information. [general] password-db = ../../passwd.conf anon-access = none auth-access = write authz-db = ../../authz.conf # realm = My First Repository

visualSVN_server权限配置使用说明

VisualSVN server使用配置说明 一、VisualSVN server的配置简介 VisualSVN Server适用于你的团队在Windows平台上使用,可以用来安装、配置和管理Subversion Server,其中包括了Subversion和一个管理控制台。你可以使用Subversion client 连接到VisualSVN Server ,也可以用浏览器来快速浏览内容. 而且它可以帮助你将Subversion整合进Visual Studio. 其官网下载地址:https://www.doczj.com/doc/d71120531.html,/server 二、VisualSVN server的安装 1、双击下载好的安装软件,出现下图 点击上图Next,进入下图所示: 点击复选框,点击Next,进入下图:

设置如上图所示,进入下图: 这里要求你填入VisualSVN Server的安装位置,以及选择服务器端口和连接协议,,在大多数情况下可以使用默认值。点击Next完成VisualSVN server的安装。

三、V isualSVN server的使用 3.1 管理控制台 VisualSVN Server 提供了一个简单和直观的标准MMC snap-in管理控制台。 你可以通过“开始菜单→所有程序”或者通过标准MMC来访问它。 通过管理控制台,你可以很方便地创建新版本库或浏览已经存在的库。同样,你可以管理对版本库的访问权限。 3.2 创建版本库 可通过右键Repositories→Create New Repositories来创建,当创建一个新的版本库时,

SVN+Apache服务器端配置及权限设置教程

SVN+Apache服务器端配置及权限设置教程

一、软件版本信息 Httpd-2.2.17-win32-x86-openssl-0.9.8o.msi Setup-Subversion-1.6.16.msi 二、软件配置信息 1.安装apache服务器和SVN服务器。 2.复制SVN服务器Subversion\bin 目录下的mod_dav_svn.so ,mod_authz_svn.so 及所 有dll 文件至apache 服务器Apache Software Foundation\Apache2.2\modules目录下3.打开apache服务器安装目录下的 \Apache Software Foundation\Apache2.2\conf\httpd.conf 文件.修改 #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so 为 LoadModule dav_module modules/mod_dav.so LoadModule dav_fs_module modules/mod_dav_fs.so 注: LoadModule前面不能有空格 在配置文件最末尾添加: Dav svn SVNParentPath "G:/svn/Repository" AuthType Basic #SSLRequireSSL AuthName "SVN Repository" SVNListParentPath on AuthUserFile "D:/Apache Software Foundation/Apache2.2/conf/conf-svn/passwd" AuthzSVNAccessFile "D:/Apache Software Foundation/Apache2.2/conf/conf-svn/authz" Require valid-user

svn用户权限管理

SVN服务器的的IP地址为:10.1.67.100 SVN服务器使用相关说明 远程登录此台机器: 密码:qdpt1234

1. repositories下的工程主要负责3个:Group 、NewBankAgent、NewBANK 2. Users是所有用户的相关信息 3. Groups是将所有用户进行的分组 4. 再分配权限的时候,只需要将组加入进去即可。 新建用户: 右击“Users”选择“create user......”,如下图所示:

弹出上框,输入新建用户的用户名和密码,点击ok就行。 新建组名称: 点击“Groups”右边显示的则全是所有组的名称。 如果需要新建组,则右击“Groups”选择“create group.......”,写好组名点击ok既可。 将用户进行分组: 以组“g_group”为例子进行说明。 右击“g_group”选择“Edit”就能看到该组下目前所有的成员。 如下图所示: 添加新成员,则选择“Add”,选择新成员,点击ok即可。 如需删除某成员,则选中该成员后点击“Remove”即可。

工程分配权限: 以工程“Group”为例子进行说明。 右击“Group”,选择“Properties”即可看到该工程对哪些组或用户是有权限的,如下图。 给组,某人进行分配权限: 在下图中选择“Add”,再根据弹出的框,选择用户或者是个人进行添加,添加进来后,再选择“Permissions”下的权限,分配读写权限。 Inherlit from parent(read/write) 继承上级所拥有的权限 No access 没有任何权限 Read only 只有读取的权限 Read/write 有读和写的权限 选好后,确定即可。

SVN配置管理应用

配置管理 保存所有更改的记录,防止改动丢失 能够快速回复到特定版本的状态 能够获取其他成员的更改 采用:Copy-Modify-Merge方式:可以多人同时修改一个文件,会有冲突的情况,更强调开发人员的交流,对于合作开发比较合适 版本地址URL明确—————— 主要操作: 把本地文件添加到文件仓库中-----初始文件导入 从SVN文件库中取出代码-----检出 更新本地文件 文件/目录改名 把文件和目录添加到文件仓库中 从SVN中删除文件 提交修改后的文件-----检入 复本内容的更新使用 导出功能:使用此功能获取一个没有SVN控制信息的工作复本; 清理:当Subversion操作中断时,会有一些残留的操作信息保留在工作复本中,这时需要进

行清理才能够重新进行工作; 生成补丁文件:可以将自己所作的修改以补丁文件的方式交给他人,对于只有匿名访问的代码可以以这种方式提交修改; 在资源管理器中显示文件的SVN信息:通过定制资源管理器的显示字段控制 经常更新:由于文件可能有多个人修改,应该经常更新你的工作拷贝中的文件,这样能降低发生冲突的可能性; 提交前先在本地进行测试:不允许将有错误的文件提交到服务器上; 提交时一定要写备注:备注有助于其他人(包括三个月后的你自己)理解你对文件所做的修改; 提交文件时注意要提交一项改动所对应的所有文件修改 使用标签和分支,账号权限的分配管理 #定义储存库下指定目录的访问权限 @admin=rw #admin组有读写权限 tests=r #test用户只有读权限 # anon-access = read # auth-access = write # password-db = passwd # realm = My First Repository 在Cmd命令行下进入到SubVersion目录下的bin目录下,输入如下命令: svnserve -d -r d:\svn_projects SVN更新然后修改文件类别、插件的安装 操作实例 安装和配置步骤: 1.安装apr-1.3.8.tar.gz tar –zvxf apr-1.3.8.tar.gz (解压) cd apr-1.3.8 (进入apr…所在的目录) ./configure /* (安装不指定路径时默认安装到/usr/local/apr) make ; make install (安装) 2. 安装apr-util-1. 3.9.tar.gz

相关主题
文本预览
相关文档 最新文档