有时候我需要确定没有人承诺到特定分支或我的主干。发布版本和重新集成合并就是一个例子。
SVN“锁定”所有文件是不现实的(很长一段时间,因为项目很大)。我也不相信锁定会阻止某人提交新文件。
在我完成我正在做的事情之前,确保没有人向文件夹提交任何内容的快速方法是什么?
由于
答案 0 :(得分:8)
如果您正在进行发布版本,那么您要做的第一件事就是查看特定版本。
如果某人在此期间提交了其他内容并不重要 - 它不会影响您的构建。
答案 1 :(得分:6)
我们在编译发布版本的项目时遇到了这个问题,其中构建服务器属性(CruiseControl.NET项目标签)用作程序集和安装程序版本的一部分。
在分支(或标记)工作副本的地方,解决方案很简单,例如:发布版本。
工作流程:
如果你想在没有分支的情况下提交你的工作副本,那么正如你所说,如果有人修改了存储库的路径,这将失败(或至少是不可靠的)。
解决此问题的方法是使用svn authorization control,将构建服务器用户添加到svn,并为存储库提供不同的authz
文件。
工作流:
authz
替换为授予构建服务器用户写入权限的文件和所有其他用户的读取权限。authz
替换为授予所有用户正常访问权限的文件。请注意,svn授权允许基于路径的控制,因此您可以将其限制为中继(或任何地方),以减少对用户的影响。
使用类似方法(相同工作流程)的另一种方法是替换pre-commit hook并检查用户;如果不是您的构建服务器用户执行提交,则拒绝提交(带有相应的错误消息)。同样,如果需要,这可能是基于路径的(有一点额外的正则表达式工作)。
答案 2 :(得分:2)
有趣的问题。听起来好像你的开发工作流程可能会有一些变化,因为你遇到了这个问题。特别是,在这样一个大型项目中,您应该考虑更受控制的工作流,因此开发更改不会同时进入,并且在同一分支上,作为正在进行的发布版本。例如,您提到了重新整合合并 - 当然,您可以协调项目,以便重新整合合并不会与发布版本同时发生。开发人员不应该直接向分支机构提交正在进行发布的内容。
的可能性:
trunk
)。
答案 3 :(得分:1)
我们首先,您可能会尝试在特定修订版上执行这些操作,而不是头部。
如果修订版不是一个选项,我接下来建议您标记要构建的修订版或其他版本并对其进行操作。这显然不适用于合并,因为它违背了目的。
但是,为了解决问题的关键,我能想到的最快捷的方法是阻止传入的信息停止服务器本身。我不是SVN专家,但我已经管了好几年了。
答案 4 :(得分:1)
根据您对服务器的访问权限,发送通知,告知任何人不要提交一段时间。
如果您不能这样做,请使用file://
或file+ssh://
结帐/签入发布版本,并在此期间关闭SVN服务器进程。 (无论是apache,还是svnserver)然后在构建完成后立即重新启动它。
另外,请务必重做,这样就不需要尽快锁定回购。 (我意识到这只是你继承的暂时的事情)
答案 5 :(得分:1)
正确的方法是我的拙见。
我就是这样做的,我有一个标记部分的脚本
#!/bin/bash
#
# Copyleft
#
#
# Use with caution
#
#
#
# This script expects 2 variables in the environment to be set : USERNAME & PASSWORD
# These are needed to access our Subversion server.
#
#
# This script tags the code of each project @ HEAD
# Later version will be more sofisticated to allow tagging at a specified REVISION (it should already be the case but ... )
#
# This script must be saved un iso-8858-1 with UNIX LF
# ##############################################################################################################################################
# for debugging
set -x
set -v
# The Current verion of the tagging script is
BASEDIR=$(dirname $0)
export BASE_SVN_URL=https://my-svn-server/svn/repository/
export ROOT_DIR=../..
export VERSION="v0000.01"
export REVISION=HEAD
export TAG_NAME=TC_05
for PRJ in MODULE_1 MODULE_2 MODULE_3
do
svn lock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert --force \
${BASE_SVN_URL)${PRJ}/trunk/ \
-m "Locking the trunk of ${PRJ} before generating a Tagged version : ${VERSION} Tag is : ${TAG_NAME}"
done
for PRJ in MODULE_1 MODULE_2 MODULE_3
do
svn copy --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert \
${BASE_SVN_URL)${PRJ}/trunk@${REVISION} \
${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME} \
-m "$1"
svn lock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert \
${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME} \
-m "Tagged version cannot be modified afterwards"
svn unlock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert --force \
${BASE_SVN_URL)${PRJ}/trunk/ \
-m "Locking before generating a Tagged version"
done
set +x
set +v
#
# TODO :
#
# 1. Ensure that the following parameters are set correctly
# _ username / password (though not mandatory)
# _ Commit message, VERSION & TAG ought to be set before start
# _ ... ?
# 2. Ensure that the directory structure exist
# 3. Ensure that the required variable are set before starting ... but anyway the script will fail :)
# 4. Check the return code of the important commands command.
# 5.
我的代码的构建位于另一个脚本中。 长脚本很酷,但在过程早期失败时往往会引发问题,导致系统处于未知状态。 提供的脚本尚未经过全面测试,也未在我们的系统中广泛使用,以确保它们没有错误。
但是我建议很少使用svn锁定。
在发布之前的最后,确保没有最后一分钟的错误不会使您的发布处于危险之中......但是良好的通信应该允许您使用几乎相同的代码但是指定提交号
\ T,
答案 6 :(得分:0)
工作完成后,可以暂时更改passwd文件。缺点是这会影响整个存储库,而不仅仅是一个文件夹。
答案 7 :(得分:0)
我需要再次推动pre-commit挂钩吗?
这可以处理很多事情,但阻止人们修改文件是它的主要推动力。您可以通过控制文件控制提交行为:
[ FILE The repository is now locked and you are no longer allowed to change files]
Match = .*
access = read-only
users = @ALL
[ File Except for me. I can do whatever I want]
match = .*
access = read-write
users = si
控制文件可以存储在存储库中,因此您不需要服务器访问。只需签出控制文件,编辑并提交即可。 (当然,预提交脚本控制对谁可以修改控制文件的访问权限!)
您可能想要做的是使用分支进行发布。我们使用Jenkins并通过Jenkins内部版本号执行所有操作。开发人员会说“我想分支构建#50,然后分支,或者让我们标记构建#51,然后标记。
当您可能想要锁定存储库时,我们会进行分支。但是,我们让开发人员继续使用主干,然后限制谁可以操作分支:
[group cm]
users = si
[group Release]
users = bob, alice
[group developers]
users = robert fred cindy @Release
[file You do not have access to make changes to this repository]
match = .*
access = read-only
users = @all
[file Let all developers work on the trunk]
file = /trunk/**
access = read-write
users = @developers
[file only release group can work on the 4.5 branch]
file = /branches/4.5/**
access = read-write
users = @release
[file You cannot edit a tag. You can only create a tag]
file = /tags/*/
access = add-only
Users = all
[file CM group can do anything]
file = .*
access = read-write
users = @CM
向下读取权限,并且您获得的最后一个权限适用于您。开发人员可以访问trunk。发布人员可以在4.5分支上工作,但不能在任何其他分支上工作。特殊add-only
访问权限允许您创建标记,但不能修改标记。 /tags/*/
表示您只能直接在标记目录下创建标记,并且它必须是从其他位置复制的目录。