我如何在Linux中设置权限,以便两个用户可以在服务器上更新相同的SVN工作副本?

我的服务器同时安装了Subversion和Apache,而Apache Web目录也是Subversion的工作副本。 原因是简单的命令svn update /server/staging会将最新的源部署到登台服务器。

Apache公共Web目录: /server/staging – (这是一个SVN的工作副本。)

我的服务器上有两个用户,'richard'和'austin'。 他们都是“开发者”组的成员。 我使用“sudo chown -R richard:developers / server”recursion地将/ server目录上的权限设置为richard:developers。

然后,我为“理查德”和“开发者”组设置读写权限。

所以当然,'奥斯汀'现在应该能够使用svn update /server/staging命令? 然而,当他尝试,他得到的错误:

 svn: Can't open file '/server/staging/.svn/lock': Permission denied 

如果我recursion地将/服务器的所有者更改为奥斯汀:开发者,他可以运行命令,但是'richard'不能。

我如何解决这个问题? 我想创build一个post-commit钩子,在提交文件时自动部署登台站点,但是我看不到为这两个用户工作的方法。 挂钩将是:

 /usr/bin/svn update /server/staging 

对他们使用相同的用户帐户将不会是一个可接受的解决scheme,我不知道有任何方式来运行命令内的钩子作为“根”。

任何帮助表示赞赏!

Solutions Collecting From Web of "我如何在Linux中设置权限,以便两个用户可以在服务器上更新相同的SVN工作副本?"

目录设置组ID

如果设置了目录条目上的setgid位,则该目录中的文件将拥有组所有权作为目录,而不是创建该文件的用户组。

当多个用户需要访问某些文件时,该属性是有帮助的。 如果用户在设置了setgid属性的目录中工作,则任何用户在目录中创建的任何文件都将具有该组的权限。 例如,管理员可以创建一个名为spcprj的组,并将用户Kathy和Mark添加到组spcprj。 可以使用设置的GID位和Kathy和Mark创建目录spcprjdir,虽然在不同的主要组中可以在目录中工作,并且可以完全访问该目录中的所有文件,但仍然无法访问彼此的主要组中的文件。

以下命令将设置目录上的GID位:

 chmod g+s spcprjdir 

目录“spcprjdir”的目录列表:

 drwxrwsr-x 2 kathy spcprj 1674 Sep 17 1999 spcprjdir 

用“s”代替组权限中的执行位将导致写入目录“spcprjdir”的所有文件都属于组“spcprj”。

编辑:源= Linux文件和文件权限

我会设置svnserve这是一个简单的Subversion服务器使用svn://协议。 您可以对其进行设置,使其在自己的用户帐户下运行,然后只能由该用户访问存储库。 然后这个用户可以拥有正确的特权来在post-commit钩子上运行svn update /server/staging

在你的svn仓库中,你可以找到一个设置权限的“conf”目录。 你有3个文件在那里:

  • AuthZ的
  • passwd文件
  • 的svnserve.conf

您在authz文件中设置哪些用户具有哪种访问权限,每个用户或每个组。 你在那里设置组,SVN组不是linux用户组(哈希行是注释):

 [groups] # harry_and_sally = harry,sally projectgroup = richard,austin # [/foo/bar] # harry = rw -- user harry has read/write access # * = -- everybody have no access # [repository:/baz/fuz] # @harry_and_sally = rw -- harry_and_sally group members have read/write access # * = r -- everyone has read access [/server/staging] @projectgroup = rw * = r 

解决这个例子,并设置你的配置。 在“passwd”文件中设置用户密码。 执行

 cat passwd 

你会得到解释如何设置注释文件。

我使用WebDAV – 所有的SVN更新和提交通过Apache处理,我从来没有这样的问题。