SVN流程规范梳理

090

之前我都是用的Git，突然使用到了SVN，发现目前的SVN流程有些原始，所以想梳理一份合理且规范的SVN流程，可以帮助我们更好的管理SVN代码仓库，不期望其优雅，期望其完善。

1. 方案

1.1 定义代码提交规范

在公司内部，应该制定特定的提交规范，以确保所有提交都遵循相同的格式和流程。例如，规定每个提交都必须包括一个有意义的提交消息，描述该提交做了什么，并且必须经过代码审查后才能合并到主干。

1.2 安排适当的权限和角色

如果在公司内部使用SVN，则需要定义一个角色和权限模型，以限制访问权限并确保相关人员可以访问他们所需的仓库部分，而不会打扰其他领域的开发者。例如，可以设置开发者组、QA组和管理员角色，并为每个角色分配适当的权限。

1.3 禁止直接在主干分支上提交代码

在公司内部使用SVN时，应该避免直接在主干分支上提交代码。主干应该被视为一个稳定分支，在任何时间点都应该保持其可部署和可测试状态。因此开发者应该在自己的分支上提交他们的更改，并在至少一个同伴进行审查，以确保他们的代码符合要求，然后再将代码合并到主干分支。

1.4 设定工作流程

设定有序的工作流程非常重要，特别是在大型项目分支和多个开发者参与的情况下。通常建议使用一个集成工作流程，其包括以下步骤：开发者在本地创建或切换到开发分支；在分支上进行开发和测试，并提交代码；代码审查通过后，合并到主干；在主干上经过自动化测试后，最终部署到生产环境。

1.5 建立合理的分支管理策略

分支管理策略非常重要，为公司提供了灵活性，添加了新功能和修补漏洞，同时又不影响主干分支的稳定性。可以考虑创建长期的维护分支，例如修补漏洞分支，以及短期的开发分支来添加新功能。在短期开发完成后，开发分支应该会被合并到固定的长期的主干分支中。

1.6 制定自动化流程

自动化流程大有益处。可以利用SVN钩子脚本进行许多有用的操作，例如：自动运行测试、检查提交的代码风格和规范、禁止提交包含脚本或二进制文件、标记每个提交的作者，以及通知相关人员进行代码审查。

2. 实现

2.1 commit默认模板

为了让提交更加规范和一致，可以在SVN上配置提交(commit)默认模板。这样，当同事进行提交时，就会自动弹出默认模板，同事只需要按照模板填写信息即可。

下面是配置提交默认模板的步骤：

2.1.1 创建提交模板文件

可以使用任意文本编辑器创建一个名为”commit-template.txt”的文件，该文件的内容是模板的文本内容。比如，将下面的模板内容保存到commit-template.txt文件中：

【提交类型】: 功能制作/BUG/代码整理/解决编译错误/资源添加/资源修改/目录调整
【修改内容】: 
【bug链接】: 
【提交类型】: 功能制作/BUG/代码整理/解决编译错误/资源添加/资源修改/目录调整
【修改内容】: 
【bug链接】: 
【提交类型】: 功能制作/BUG/代码整理/解决编译错误/资源添加/资源修改/目录调整
【修改内容】: 
【bug链接】:

上述模板包含一个问题标识符、一个说明以及一个审阅人列表，可以根据需要进行调整。

2.1.2 编辑hooks/pre-commit挂钩脚本

打开hooks目录下的pre-commit脚本，使用编辑器打开这个文件，添加以下代码行：

#!/bin/sh
REPOS="$1"
TXN="$2"
svnlook propget --transaction $TXN svn:log "$REPOS" > /tmp/svn-commit.tmp
/usr/bin/perl -p -i -e 'eof && print "\n\nIssue ID: \nDescription: \nReviewers: \n"' /tmp/svn-commit.tmp
/usr/bin/vi /tmp/svn-commit.tmp
SVN_EDITOR_RESULT=$?
/bin/rm -f /tmp/svn-commit.tmp
exit $SVN_EDITOR_RESULT
#!/bin/sh




REPOS="$1"

TXN="$2"



svnlook propget --transaction $TXN svn:log "$REPOS" > /tmp/svn-commit.tmp


/usr/bin/perl -p -i -e 'eof && print "\n\nIssue ID: \nDescription: \nReviewers: \n"' /tmp/svn-commit.tmp
/usr/bin/vi /tmp/svn-commit.tmp

SVN_EDITOR_RESULT=$?


/bin/rm -f /tmp/svn-commit.tmp

exit $SVN_EDITOR_RESULT
#!/bin/sh




REPOS="$1"

TXN="$2"



svnlook propget --transaction $TXN svn:log "$REPOS" > /tmp/svn-commit.tmp


/usr/bin/perl -p -i -e 'eof && print "\n\nIssue ID: \nDescription: \nReviewers: \n"' /tmp/svn-commit.tmp
/usr/bin/vi /tmp/svn-commit.tmp

SVN_EDITOR_RESULT=$?


/bin/rm -f /tmp/svn-commit.tmp

exit $SVN_EDITOR_RESULT

上述代码的作用是：

  • 在pre-commit脚本执行前，调用svnlook propget命令将提交消息提取到/tmp/svn-commit.tmp文件中；
  • 在/tmp/svn-commit.tmp文件的末尾添加一个区域，以便用户在提交之前填写模板的信息；
  • 打开/tmp/svn-commit.tmp文件，让用户可以编辑提交消息和模板信息；
  • 以vi编辑器打开/tmp/svn-commit.tmp文件进行编辑；
  • 当用户完成文件编辑后，脚本会检查编辑器的退出状态码，以检查用户是否确认提交；
  • 如果用户编辑器退出状态码为0，表示确认提交，则从/tmp/svn-commit.tmp文件中提取提交消息，并使用svnlook propset –transaction命令将提交消息保存到SVN。

2.1.3 保存此文件并将它赋予执行权限

chmod +x hooks/pre-commit
chmod +x hooks/pre-commit
chmod +x hooks/pre-commit

2.1.4 测试

现在可以使用SVN进行提交并看到提交消息指向一个编辑器模板界面，让用户将想要填写的字段填入其中并提交。下面是一个示例提交模板：

[default]
【提交类型】:  (请在此处输入您的提交类型)
【修改内容】: (请在此处输入您的修改内容)
【bug链接】: (如果是bug修改，请在此处输入您的bug链接)
[default]



【提交类型】:  (请在此处输入您的提交类型)
【修改内容】: (请在此处输入您的修改内容)
【bug链接】: (如果是bug修改，请在此处输入您的bug链接)
[default]



【提交类型】:  (请在此处输入您的提交类型)
【修改内容】: (请在此处输入您的修改内容)
【bug链接】: (如果是bug修改，请在此处输入您的bug链接)

要点：

  • 默认模板可以通过在hooks/pre-commit脚本中指定的任何文件路径中提供来定义；

  • 该模板可以使用配置选项进行编辑和自定义，以更好地适应组织特定的工作流；

  • 该模板的任何模板都将在用户编辑项中展示，以使用户能够直接修改应提交的值，而无需手动输入提交文本。

2.2 强制提交

要让每个提交都必须包括有意义的提交消息，可以通过使用SVN钩子脚本实现。SVN钩子脚本是SVN服务器上的脚本，用来在特定事件触发时运行预定义的操作。其中一个事件是”pre-commit”事件，该事件在检查执行提交操作之前触发。通过编写”pre-commit”脚本，可以要求用户输入提交消息，然后对其进行校验，以确保提交消息符合规范。

下面是一些实现SVN提交消息规范的配置步骤:

2.2.1 查找”pre-commit”脚本的位置

在安装了SVN服务器的主机上，需要找到SVN存储库的hooks目录。预定义的”pre-commit.tmpl”脚本在这个目录下，可以将其复制一份并改名为”pre-commit”。

cd /path/to/repo/hooks/
cp pre-commit.tmpl pre-commit
cd /path/to/repo/hooks/
cp pre-commit.tmpl pre-commit
cd /path/to/repo/hooks/
cp pre-commit.tmpl pre-commit

2.2.2 修改”pre-commit”脚本

可以打开”pre-commit”脚本，在文件末尾添加以下内容：

# Check that log messages are at least 10 characters long
REPOS="$1"
TXN="$2"
LOG=`$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c`
if [ "$LOG" -lt 10 ]; then
  echo >&2 "Commit message must be more than 10 characters in length"
  exit 1
fi
# Check that log messages are at least 10 characters long
REPOS="$1"
TXN="$2"

LOG=`$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c`


if [ "$LOG" -lt 10 ]; then
  echo >&2 "Commit message must be more than 10 characters in length"
  exit 1
fi
# Check that log messages are at least 10 characters long
REPOS="$1"
TXN="$2"

LOG=`$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c`


if [ "$LOG" -lt 10 ]; then
  echo >&2 "Commit message must be more than 10 characters in length"
  exit 1
fi

上述脚本会检查提交消息的长度是否大于10个字符，如果小于10个字符，则会输出错误信息，并且在退出时返回一个非零的状态码，导致提交命令中止。

2.2.3 校验脚本语法和权限

在对”pre-commit”脚本进行配置后，需要校验其语法和权限。可以使用以下命令校验”pre-commit”脚本的语法：

/path/to/repo/hooks/pre-commit check-params "$REPOS" "$TXN"
/path/to/repo/hooks/pre-commit check-params "$REPOS" "$TXN"
/path/to/repo/hooks/pre-commit check-params "$REPOS" "$TXN"

如果脚本检查通过，那么如果有新代码，就可以像往常一样通过提交命令提交代码。提交时，SVN会对提交消息进行检查，如果提交消息长度不够，则会输出错误消息，阻止提交。

上述步骤是让每个提交都必须包括有意义提交消息的一种方法，可以通过类似的钩子脚本来实现其他自定义要求。

2.3 代码审核

为了确保代码质量和一致性，可以在SVN上配置代码审核后才能将代码提交到主干。这意味着提交前需要经过至少一个人的审核，以确保代码符合组织的标准和最佳实践。

下面是配置代码审核的步骤：

2.3.1 安装代码审核工具

首先需安装代码审核工具，推荐使用Review Board或Phabricator等流行的代码审查工具，这些工具可以帮助你轻松地进行代码审核。

2.3.2 配置代码审核工具

配置代码审核工具，以确保它与您的SVN存储库集成，并且审核人员可以访问存储库中的提交。

2.3.3 编辑hooks/pre-commit挂钩脚本

打开hooks目录下的pre-commit脚本，使用编辑器打开这个文件，添加以下代码行：

#!/bin/sh
REPOS="$1"
TXN="$2"
/usr/local/bin/rb-post-review --username=svn --password=password --server=http://reviews.example.com --submit-as=<user-email> --svn-username=svn --svn-password=password --diff-only --revision-range $TXN:$TXN --repository-url=svn://svnrepo.example.com/repo --proxy=proxy.example.com:8080
# Check the response from post-review for "New Review Request created" or something similar.
#
# If "New Review Request created" then the hook script proceeds and exits normally.
# If anything else is returned from post-review (e.g. failure to create new review request),
# then the hook script fails, which causes the commit to fail on the client side.
exit 0
#!/bin/sh




REPOS="$1"

TXN="$2"



/usr/local/bin/rb-post-review --username=svn --password=password --server=http://reviews.example.com --submit-as=<user-email> --svn-username=svn --svn-password=password --diff-only --revision-range $TXN:$TXN --repository-url=svn://svnrepo.example.com/repo --proxy=proxy.example.com:8080


# Check the response from post-review for "New Review Request created" or something similar.
#
# If "New Review Request created" then the hook script proceeds and exits normally.
# If anything else is returned from post-review (e.g. failure to create new review request),
# then the hook script fails, which causes the commit to fail on the client side.

exit 0
#!/bin/sh




REPOS="$1"

TXN="$2"



/usr/local/bin/rb-post-review --username=svn --password=password --server=http://reviews.example.com --submit-as=<user-email> --svn-username=svn --svn-password=password --diff-only --revision-range $TXN:$TXN --repository-url=svn://svnrepo.example.com/repo --proxy=proxy.example.com:8080


# Check the response from post-review for "New Review Request created" or something similar.
#
# If "New Review Request created" then the hook script proceeds and exits normally.
# If anything else is returned from post-review (e.g. failure to create new review request),
# then the hook script fails, which causes the commit to fail on the client side.

exit 0

上述代码的作用是：

  • 从存储库中提取提交，并将其作为差异(Diff)文件提交到Review Board或Phabricator；
  • 如果代码审核人员批准提交，则提取提交差异，将其合并到存储库中，并将审核结果更新到审核工具；如果代码审核人员未批准提交，则阻止提交，以便进行必要的修改。

2.3.4 保存此文件并将它赋予执行权限

chmod +x hooks/pre-commit
chmod +x hooks/pre-commit
chmod +x hooks/pre-commit

使用此设置，代码审核人员可以轻松访问存储库中的提交，并可以使用他们喜欢的代码审核工具对其进行审查，并在批准提交后将其合并到存储库中。通过此方法，可以确保所有提交都符合组织的标准和最佳实践。

2.4 分配权限

在SVN中，可以为每个用户和组分配不同的权限。这些权限的分配可以控制用户能够访问存储库的哪些部分以及可以执行哪些操作。以下是在SVN上给员工分配不同权限的一些步骤：

2.4.1 创建用户和组

首先创建用户和组。在SVN中，可以使用htpasswd工具创建用户，并使用htdigest工具创建组。例如：

htpasswd -c /path/to/svn/passwdfile username1
htdigest -c /path/to/svn/authzfile group1
htpasswd -c /path/to/svn/passwdfile username1
htdigest -c /path/to/svn/authzfile group1
htpasswd -c /path/to/svn/passwdfile username1
htdigest -c /path/to/svn/authzfile group1

2.4.2 创建存储库配置文件

使用编辑器打开存储库配置文件，在文件底部添加以下内容：

[groups]
group1 = username1, username2, username3
[myrepo:/branches/dev]
@group1 = r
[myrepo:/branches/qa]
@group1 = r
[myrepo:/branches/feature1]
username1 = rw
[myrepo:/branches/feature2]
username1 = rw
username2 = r
[groups]
group1 = username1, username2, username3

[myrepo:/branches/dev]
@group1 = r


[myrepo:/branches/qa]
@group1 = r

[myrepo:/branches/feature1]
username1 = rw


[myrepo:/branches/feature2]
username1 = rw
username2 = r
[groups]
group1 = username1, username2, username3

[myrepo:/branches/dev]
@group1 = r


[myrepo:/branches/qa]
@group1 = r

[myrepo:/branches/feature1]
username1 = rw


[myrepo:/branches/feature2]
username1 = rw
username2 = r
  • [groups]: 指定用户组，并将组成员添加到其中。
  • [myrepo:/branches/dev]: 指定了对存储库的某个目录分支的权限。
  • @group1: 将组“group1”的所有成员分配给了“dev”和“qa”分支的“读”权限。
  • username1: 为用户“username1”分配了“写”权限，并将其添加到“车道1”和“车道2”的分支中。
  • username2 = r: 为用户“username2”分配了“只读”权限，并将其添加到“车道2”的分支中。

2.4.3 保存此文件并添加密码文件

在上述配置完成后，需要将此文件保存，然后使用htpasswd工具将用户名和密码添加到密码文件中，并确保此密码文件可读。

htpasswd /path/to/svn/passwdfile username2
htpasswd /path/to/svn/passwdfile username2
htpasswd /path/to/svn/passwdfile username2

通过以上操作，可以分配不同的权限给不同的用户和组。在实践中，可以根据需要进行修改。重要的是，将用户和组分配到适当的存储库目录上，并细致地授予适当的权限，以确保代码的保密性和安全性。

2.5 分支管理策略

建立一个合理的分支管理策略可以确保团队在开发和维护项目时具有良好的版本控制，提高工作效率和代码质量。以下是一些建立合理的分支管理策略的步骤：

  1. 主分支（Main Branch）：主分支是项目的中心分支。它应该存储所有的代码，并是代码库的“稳定”分支。主分支应该是只读的，只允许合并已经批准的代码到它里面。例如，可以将主分支命名为“Trunk”、“Mainline”、“Master”等。

  2. 开发分支（Development Branches）：开发分支是从主分支创建的分支，它用于开发新功能和修复问题。开发人员可以在不影响主分支的情况下，进行他们的实验室实验和创建新功能。一旦开发完毕，应该将分支中的修改合并回主分支。例如，可以将开发分支命名为“dev”、“develop”、“feature”等。

  3. 发布分支（Release Branches）：发布分支通常在团队准备发布一个版本时创建。它使开发人员能够继续修复任何问题、增加必要的动作或其他修改，而不会影响呈现内部/外部用户的已发布版本。一旦发布分支成功，应该将所有更改合并回主分支，以防止在新开发中出现问题。例如，可以将发布分支命名为“release”等。

  4. Hotfix分支（Hotfix Branches）：当主分支中出现严重的bug或安全问题时，应该从主分支创建一个hotfix分支来修补问题。修复后，应该将所有更改合并回主分支和分支供发布。例如，可以将hotfix分支命名为“hotfix”等。

重要的是，确保分支管理策略清晰和可执行，并与整个团队相同，在执行过程中适时进行检查和调整以获取更好的结果。

2.6 自动化测试

要在SVN中配置自动化测试，需要以下步骤：

  1. 确认SVN上的代码库是否与同步的测试环境相同。如果测试环境与代码不同，则需要使用版本控制工具掌握版本和更改的准确位置和时间，以便进行快速问题诊断和修复。

  2. 确认自动化测试框架和测试脚本是否已准备好且能够与SVN协同工作。 可能需要使用版本控制工具来存储测试框架和脚本，并确保测试工具可以自动从SVN中拉取或导入代码。

  3. 配置自动化测试套件以按照代码变更自动运行测试，并使用版本控制工具管理测试用例。在每次代码更改后，应运行测试套件，以确保不会影响现有工作流程。可以使用各种持续集成/持续交付工具（如Jenkins、Travis CI等）来自动触发测试。

  4. 将测试结果回流到SVN中，以便团队共享测试结果并追踪问题。可以使用各种测试报告工具（如Junit、TestNG等）将测试结果输出到XML或HTML格式，并使用SVN存储和管理这些报告。在较大的团队中，可能需要使用工具组合和/或自定义脚本来帮助自动化测试结果的管理和回流。

需要注意的是，自动化测试是持续演进的，需要团队的不断学习和尝试。通过持续改进自动化测试策略，并在SVN中进行配置和管理，可以帮助团队在软件开发的全生命周期中提高质量和效率。

2.7 commit整合

SVN通常使用“合并（merge）”来将修复或功能性单独提交整合进主分支中。 SVN有以下几个合并策略可供选择：

  1. 详细合并（Full Merge）：将所有提交的更改全部整合到主分支。这与常规合并相同。

  2. 根据记录进行合并（Merge by Record）：仅将记录相同的提交进行合并。这种方法很容易出错，因为记录可能不准确，而且需要管理者的亲自审查。

  3. 两阶段合并（Two-Phase Merge）：这种方法是使用详细合并在独立的分支中先进行合并，以确定是否存在任何新问题，然后再使用严格的策略整合回主分支。

对于第三种方法，以下是一些常见的步骤：

  1. 从主分支中创建一个新的临时分支，以用于合并批准的补丁或修复。这个分支不需要一直存在，只需要在两个阶段的过程中临时使用。

  2. 将新的更改或补丁提交到临时分支。

  3. 对临时分支进行详细合并，以确保所有更改都成功整合到临时分支中。

  4. 进行第一阶段合并，将临时分支与主分支合并，但不要将新的更改合并回主分支中。这样可以确保新的更改不会对主分支造成影响。

  5. 这个时候，可以对新的更改进行测试和审查，以确保高质量的代码可以合并回主分支。

  6. 进行第二阶段合并，将临时分支与主分支进行详细合并，以确保所有更改都被整合进去。

  7. 删除临时分支并打上一个合并标签，以便在以后检查。

在进行SVN的合并过程时，应该始终遵循最佳实践和合理的策略，以确保代码质量和管理。使用版本控制工具进行管理和审查可以减少错误和冲突，同时也可以提供一个有条不紊的开发流程。

2.8 Git和SVN一起使用

将Git提交的代码合并到SVN上需要以下步骤：

  1. 设置一个SVN代码库用于存储Git代码。可以使用svnserve、Apache HTTP Server或其他SVN服务器软件来设置SVN库。

  2. 将SVN库中已有的代码检出到Git仓库的本地目录下，通过git checkout命令可以将SVN库中的代码下载到本地。

  3. 将Git代码push到SVN代码库。可以使用Git-svn的合并功能将需要提交的代码合并到SVN的分支上，再将代码push到SVN库中。

  4. 处理冲突。由于Git和SVN是不同的版本控制系统，Git和SVN之间可能会出现代码冲突或版本控制问题。在将Git代码合并到SVN时，需要手动检查和解决可能存在的冲突，并确保代码具有一致性。

  5. 提交到SVN库中。在冲突解决后，可以使用svn commit命令将Git代码提交到SVN库中。

需要注意的是，在将Git代码提交到SVN库中时需要遵循团队的指导方针和最佳实践，以确保代码质量和管理。同时在使用Git-svn进行合并时，还需要掌握Git和SVN的基本知识，以确保代码合并的正确性和可行性。

3. 总结

基础建设还是很重要的，完善的基础建设会提高开发者们的效率，让开发者们大部分的时间都是在做项目，而不是在解决代码冲突，代码覆盖，代码丢失等问题。

那么上面的规范可以给我们带来哪些增益呢？

  1. 提升代码质量和可维护性：一个良好的前端基础建设可以帮助我们规范前端代码的编写，使得代码质量更高，更易于维护和排错，并且能够避免由于不规范的代码造成的冗余、重复、和难以维护的问题。

  2. 提高开发效率：通过对基础建设的优化和升级，可以提高开发人员的开发效率，降低开发成本和时间，并且减少了代码错误率，提高团队工作效率。

  3. 确保团队合作和协同：前端基础建设还可以提供一个统一的前端框架和规范，使得各个开发人员可以遵守同样的开发规则和标准，协同工作更加顺畅。

  4. 改善用户体验：前端基础建设不仅可以提高前端开发效率和代码质量，同时也能够改善用户的体验，例如使用更快的加载速度和更友好的界面设计实现更好的用户体验。

© 版权声明
文章版权归作者所有，未经允许请勿转载，侵权请联系 admin@trc20.tw 删除。
THE END
前端
# 前端# JavaScript# SVN
喜欢就支持一下吧
点赞0

Warning: mysqli_query(): (HY000/3): Error writing file '/tmp/MYDzzhzR' (Errcode: 28 - No space left on device) in /www/wwwroot/583.cn/wp-includes/class-wpdb.php on line 2345
admin的头像-五八三
相关推荐
评论 抢沙发
头像
欢迎您留下宝贵的见解！
提交
头像

昵称

图形验证码
取消
昵称

请填写用户信息：

  • 昵称(必填)
  • 邮箱(必填)
代码

请输入代码：

确认
图片
文章目录
文章目录
热门推荐