SVN提交规范
SVN使用原则
以下是我起草的部门SVN规范里原则的一部分。
1. 文件提交时要求必须提交注释，注明相关修改信息，例如bug号、任务描述等。
具体内容可采用约定或者设置的形式。
2. 你所提交的改变将体现给其他开发者，要明白提交的后果，提交之前要慎重。
3. 代码变动及时提交，避免丢失本地修改后无法恢复。
4. 在提交之前要编译代码并修正错误。
要保证新增加的文件同时被提交，否则只在你本地能正常工作，导致其它人不能编译通过。
5. 提交之前要测试所改变的应用，测试改变后的效果是否达到预期的目的。
6. 多次检查提交的内容。
提交之前应先做SVN更新或与资源库同步，注意到SVN关于冲突、错误的信息。
资源库同步会告诉你将要提交的内容与资源库内容之间的差别，确认它们是不是你真正想要提交的。
7. 尊重其他开发者的代码，在重大变更之前与他们协商。
SVN并不能替代开发者之间的交流。
8. 提前宣布修改计划。
当你计划进行修改，需要影响到SVN里的许多文件时，先通过邮件或者当面通知其他开发者。
例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。
这样其他开发者会有准备，也会对修改提出意见和建议。
9. 使用自动提交。
SVN一次可以提交多个文件，所以，请一次提交所有相关的文件，即使它们不在目录下。
这样可以确保代码在提交前后都是正确的。
10. 不要将格式修正和代码修正混合提交。
修正代码格式包括增加缩进、减少空格等，如果把它们同代码修正一起提交，很难从日志或资源库同步信息里发现代码的修正。
所以应该把修正问题与修正格式分开提交。
11. 每次提交尽量是一个最小粒度的修改。
比如一个debug提交一次，一个小功能提交一次。
12. 每日进行开发工作之前更新代码。
避免与昨天其他开发者的代码冲突。
13. 所有的代码文件编码格式应该是UTF-8的。
包括的类型如java, jsp, xml, php, html等。
14. 提交的文件必须是开发者共用的程序文件，私人测试程序、程序缓存、图片缓存文件不要提交到SVN里。
SVN管理规范
SVN管理规范SVN（Subversion）是一种版本控制系统，用于管理和追踪软件开发过程中的代码变化。
为了确保团队协作的高效性和代码管理的规范性，制定SVN管理规范是非常重要的。
本文将详细介绍SVN管理规范的各个方面，包括仓库结构、分支管理、提交规范、合并策略等。
一、仓库结构为了便于团队成员之间的协作和代码的管理，建议在SVN中采用以下的仓库结构：1. trunk：主分支，用于存放主要的开发代码；2. branches：分支目录，用于存放各个开发者或团队的个人分支；3. tags：标签目录，用于存放发布的版本或重要的里程碑。
二、分支管理分支是为了并行开发和独立测试而创建的，以下是关于分支管理的规范：1. 每个开发者或团队在开始新的功能开发时，应该基于trunk创建一个新的分支；2. 分支的命名应该具有描述性，可以包括开发者或团队的名称和功能的简要描述；3. 当功能开发完成并通过测试后，将分支合并回trunk；4. 不再需要的分支应该及时删除，以保持仓库的整洁。
三、提交规范为了保证代码的质量和可追溯性，提交代码时需要遵循以下规范：1. 提交前应先更新本地代码，确保与最新版本保持一致；2. 提交的代码应该经过本地测试，确保没有明显的错误；3. 每次提交应该只包含一个功能或修复一个bug的代码变更；4. 提交时需要提供有意义的提交消息，描述本次提交的目的和内容；5. 避免提交无关的文件或代码，例如临时文件、日志文件等。
四、合并策略合并是将不同分支上的代码变更合并到一起的过程，以下是关于合并的规范：1. 在合并代码之前，应该先更新本地代码，确保与最新版本保持一致；2. 合并时应该选择合适的合并策略，例如合并所有的变更或只合并特定的变更；3. 合并后需要进行本地测试，确保合并后的代码没有冲突和错误；4. 合并完成后，及时提交合并后的代码变更。
五、权限管理为了保护代码的安全性和保密性，需要进行适当的权限管理：1. 仓库管理员应该负责管理SVN仓库的用户和权限；2. 每个开发者或团队应该拥有自己的账号，并分配适当的权限；3. 不同的分支或目录可以设置不同的权限，以控制代码的访问权限；4. 定期检查和更新用户权限，确保权限的合理性和安全性。
SVN管理规范
SVN管理规范SVN（Subversion）是一种版本控制系统，用于管理和跟踪软件开发过程中的各个版本。
为了保证团队协作的高效性和代码管理的规范性，制定一套SVN管理规范是非常重要的。
本文将详细介绍SVN管理规范的标准格式，包括仓库结构、分支策略、提交规范等内容。
一、仓库结构1. 主干（trunk）：主要用于存放稳定版本的代码，即可发布的版本。
2. 分支（branches）：用于开发新功能、修复bug等临时性任务的分支。
3. 标签（tags）：用于标记重要的里程碑版本，一般不允许修改。
二、分支策略1. 功能分支：每个新功能开发都应创建一个独立的功能分支，命名规则为feature/功能名。
2. 修复分支：修复bug时创建的分支，命名规则为bugfix/bug编号。
3. 发布分支：用于发布稳定版本，命名规则为release/版本号。
4. 主干合并：功能分支和修复分支开发完成后，需要合并到主干分支，并及时删除不再需要的分支。
三、提交规范1. 提交频率：每个提交应该只包含一个逻辑上完整的修改，避免将多个无关的修改混在一起提交。
2. 提交注释：每次提交都需要写明清晰的注释，描述本次提交的目的和修改内容。
3. 提交前检查：在提交前，应先进行代码的自测和自查，确保提交的代码没有错误和遗漏。
4. 提交权限：只有经过授权的开发人员才能提交代码，其他人员只能通过提出请求的方式。
四、冲突解决1. 更新代码：在开始新的开发或修改之前，应先更新本地代码，以避免与他人的修改冲突。
2. 解决冲突：当发生代码冲突时，应及时与相关人员协商解决冲突，并确保解决后的代码能够正常编译和运行。
五、版本管理1. 标记版本：每个重要的里程碑版本都应该在标签下进行标记，以便于后续查找和回溯。
2. 版本回退：如果某个版本出现了严重的问题，可以通过回退到之前的稳定版本来解决问题。
六、备份与恢复1. 定期备份：应定期对SVN仓库进行备份，以防止数据丢失或损坏。
SVN管理规范
SVN管理规范一、背景介绍版本控制是软件开发中非常重要的一环，它能够帮助团队协作开发、追踪代码变更、解决冲突等。
SVN（Subversion）是一种常用的集中式版本控制系统，被广泛应用于软件开发领域。
为了保证团队的代码管理效率和代码质量，制定一套SVN管理规范是非常必要的。
二、SVN仓库结构1. 主干（trunk）：存放主要的开发代码，是项目的核心分支。
2. 分支（branches）：存放项目的衍生分支，如功能开发、bug修复等。
3. 标签（tags）：存放项目的重要里程碑版本，如发布版本、里程碑版本等。
三、SVN提交规范1. 提交频率：开发人员应当保持适度的提交频率，避免过于频繁或过于集中的提交。
2. 提交注释：每次提交都应附带有明确的注释，描述本次提交的目的和内容。
3. 文件命名：文件名应具有描述性，避免使用含糊不清的命名，以便他人能够快速理解文件的作用。
4. 代码格式化：提交前应确保代码的格式化和风格统一，遵循团队的代码规范。
四、分支管理规范1. 分支创建：根据需要，合理创建分支，每个分支应有明确的目的和作用。
2. 分支命名：分支名称应具有描述性，能够清楚地表达分支的用途。
3. 分支合并：分支开发完成后，应及时将其合并回主干或其他适当的分支。
4. 分支删除：不再需要的分支应及时删除，以减少仓库的冗余。
五、冲突解决规范1. 更新代码：在进行任何修改之前，应先更新代码，确保自己的工作区是最新的。
2. 解决冲突：在提交代码时，如果出现冲突，应及时解决冲突，并确保代码的正确性。
3. 协作沟通：如果遇到无法解决的冲突，应及时与相关人员沟通，共同协商解决方案。
六、权限管理规范1. 权限分配：根据团队成员的角色和职责，合理分配SVN的读写权限。
2. 保密措施：对于敏感信息或机密代码，应严格限制访问权限，确保信息的安全性。
3. 定期审核：定期对权限进行审核，及时删除不再需要的用户账号，确保权限的及时更新。
SVN管理规范
SVN管理规范一、引言版本控制是软件开发过程中必不可少的一环，它可以帮助团队协作开发、追踪代码变更、管理代码库等。
SVN（Subversion）是一种常用的集中式版本控制系统，本文旨在为团队提供一套SVN管理规范，以确保代码库的稳定性、安全性和可维护性。
二、代码库结构1. 代码库的根目录应该包含以下目录：- trunk：主要开发分支，包含最新的稳定版本。
- branches：用于存放各个功能或版本的分支。
- tags：用于存放发布版本的标签。
2. trunk目录下的子目录结构应该清晰明确，可以按照模块、功能或项目进行划分。
三、代码提交规范1. 提交前必须先更新代码库，确保本地代码与服务器代码同步。
2. 提交时需要填写提交信息，包括但不限于以下内容：- 提交的目的和原因。
- 修改的文件或目录。
- 修改的内容和具体变动。
3. 提交信息应该简明扼要，清晰明了，便于其他开发人员理解和追踪。
四、分支管理规范1. 开发新功能或修复bug时，应该在branches目录下创建相应的分支。
2. 分支的命名应该具有描述性，可以包含功能名称、版本号或修复的问题编号。
3. 分支创建后，应该及时通知相关人员，确保团队成员都知道该分支的存在和目的。
4. 在分支上进行开发或修复时，应该定期合并主干代码，以便及时获取最新的代码变更。
5. 分支开发或修复完成后，应该及时合并到主干，并进行相应的测试和验证。
五、标签管理规范1. 发布版本时，应该在tags目录下创建相应的标签。
2. 标签的命名应该包含版本号和发布日期，以便快速定位和识别。
3. 标签创建后，应该禁止对其进行修改，以确保发布版本的稳定性和一致性。
六、权限管理规范1. 对于代码库的访问权限，应该根据团队成员的角色和职责进行分配。
2. 应该定期审查和更新权限，确保只有合适的人员能够访问和修改代码库。
七、备份与恢复规范1. 定期备份代码库，以防止数据丢失或损坏。
2. 备份数据应该存储在安全可靠的地方，确保可随时恢复。
SVN管理规范
SVN管理规范引言概述：SVN（Subversion）是一种版本控制系统，用于管理和追踪软件开辟过程中的代码变动。
在团队协作中，遵循一套SVN管理规范能够提高工作效率，减少冲突和错误。
本文将详细介绍SVN管理规范的五个方面。
一、代码库管理1.1 创建代码库：在开始新项目时，应创建一个新的代码库，并为其选择一个故意义的名称。
1.2 组织代码库结构：代码库应按照项目的逻辑结构进行组织，例如按照模块或者功能进行划分。
1.3 设置权限控制：根据团队成员的职责和权限，设置合适的权限控制，以保护代码的安全性。
二、代码提交规范2.1 提交前代码检查：在提交待码之前，进行必要的代码检查，包括代码风格、命名规范等。
2.2 提交注释规范：每次提交待码时，都应添加故意义的注释，解释该次提交的目的和内容。
2.3 避免提交冗余代码：只提交必要的代码变动，避免提交无关的文件或者代码片段。
三、分支管理3.1 创建分支策略：根据项目的需要，制定合适的分支策略，例如主干分支、开辟分支、发布分支等。
3.2 分支合并规范：在合并分支时，应先进行代码冲突的解决，确保合并后的代码是可编译和可运行的。
3.3 定期清理分支：及时清理已经合并或者再也不需要的分支，以保持代码库的整洁和可维护性。
四、版本标签管理4.1 创建版本标签：在重要的里程碑或者发布时，应创建版本标签，方便后续的回溯和版本控制。
4.2 标签命名规范：标签名称应具有一定的规范性，例如采用版本号或者发布日期等。
4.3 标签使用说明：在创建标签时，应提供相应的使用说明，包括如何部署和回滚等操作。
五、冲突解决与协作5.1 及时解决冲突：当多个团队成员同时修改同一个文件时，可能会产生冲突，应及时解决冲突，以避免代码丢失或者错误。
5.2 协作规范：团队成员之间应保持良好的沟通和协作，避免相互之间的代码冲突和误操作。
5.3 版本回溯与恢复：在发生错误或者问题时，可以通过版本回溯和恢复操作，将代码库恢复到之前的状态。
项目规范文档-SVN使用规范
SVN使用规范事项：
1、新增：要想你的库中添加文件的话，在 Windows 的资源管理器中选择要添
加的项目，然后点击右键并选择TortoiseSVN->Add选项。
2、提交：在SVN上提交新增资源或修改过的资源。
SVN 将会标记这些选择的文
件并准备添加到库中。
右键点击项目目录，并选择TortoiseSVN->SVN Commit。
这将会扫描目录中有过变化的文件或者新增的文件，并在提交对话框中显示。
点击OK即可完成文件提交。
注：说明此次修改都改动了什么！
4、更新：在需要更新的文件夹空白处右单机，显示如下界面：
选择SVN Update，SVN会自动更新服务器文件。
注意：
1、上传完SVN记得在钉钉“凌景VR研发部”工作群中文字加截图说明修改内容。
2、在进行提交修改之前问一下部门其它可能会操作该项目的人员，是否会存在冲突，
确认无冲突后再提交。
SVN的代码正确提交方法
SVN的代码正确提交方法想必大家现在都比较喜欢使用svn(subversion)完成代码管理了，因为它的开源，轻巧，易用。
但是这样一个宝贝如果不知道其正确的用法，也会让我们百思不得其解，甚至耽误项目进度，浪费程序员的心血和结晶。
下面就我们在外事项目中使用SVN的经验简单做个说明。
如何正确提交代码？可能很多人用过微软的VISUAL SOURCESAFE 或者Team Foundation Server，就认为那还不简单，checkout/checkin 不就完了吗。
孰不知由于SVN采用了另一种源代码管理机制(merge模式）,而微软采用的是传统的(lock/unlock）机制，由于机制不同，提交方式也不同。
LOCK模式更适合小团队工作，谁修改，谁加锁，提交后解锁。
MERGE模式却是谁都可以修改，而后提交时通过比较和合并解决分歧。
所以，大家要按如下方式更新才能正确提交。
常见情况是：假定项目名称是FAMS。
(一) 用户张三CHECKOUT 了 FAMS的 revision 101，然后开始工作。
(二）用户李四CHECKOUT 了 FAMS的 revision 101，然后开始工作。
(三) 现在李四完成了工作，进行提交，SVN 版本号变为revision 102，一切OK.(四) 现在张三完成了工作，也要进行提交，由于其工作的基础版本（workingbase）是revision 101,这时SVN会提示版本已过期，需要先更新(svn-update).但这时真正的问题就来了：注意SVN的机制是提交时合并，如果它发现服务器上文件版本比本地文件版本新，它会自动把服务器上的文件更新到本地，如果这个文件李四从未改过，一切OK，更新就可以了。
但是，如果李四也对此文件比如名字叫 fillform.java做了修改, 这又分三种情况：第一种情况：李四新增方法或内容，张三也是新增的内容，各不冲突，一切OK，SVN会自动合并。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SVN提交规范文件编号：
SVN提交规范
第 1 页共5页
SVN提交规范文件编号：
修订记录
第 2 页共5页
SVN提交规范文件编号：
目录
1、规范的目的 (3)
2、术语和定义 (4)
3、适用范围 (4)
4、参考和引用 (4)
5、细则 (4)
6、补充说明 (5)
1、规范的目的
本规范规定在产品开发过程中涉及的代码在SVN上的提交规则，确保分类清晰、提交格式统一、
第 3 页共5页
SVN提交规范文件编号：
简洁、便于管理。
2、术语和定义
代码：包括软件开发过程中从开发商获取的源代码、自己开发的代码、针对测试反馈的bug进行修改的代码。
工作目录：软件开发人员本地主机或者编译服务器上，用于调试问题、解决BUG的源代码目录。
编译目录：软件开发人员本地主机或者编译服务器上，用于编译版本、提交代码到SVN的源代码目录。
模块名：为本次提交代码的主要模块名称，采用全大写字母标识，尽量与程序中模块的命名相同，且前后应保持一致，不应同一模块出现多种不同的命名方式。
3、适用范围
本规范适用于规范研发体系所有软件工程师的SVN提交。
4、参考和引用
5、细则
5.1 SVN注释
SVN的提交时对注释的规范：
1、注释文字可以使用中文或英文，推荐使用中文，要求都能清晰表述要表达的意思
2、注释说明符合要求的格式以及内容完整，包括如下的内容：
格式要求：注释包括2个部分，中间用“| ”隔开，第一个部分描述操作的类别；第二部分对该操作的目的、方法、可能的注意事项进行描述。
第一部分的第一个词为类别关键词，具体分类和关键词如下：
Vendor：供应商提供的原始代码加入SVN进行受控管理
Develop：支持新特性的开发提交代码，包括功能优化和性能提升等的相关开发工作
Bug：开发阶段完成后，各测试环节反馈的问题修改，包括测试部、现场、工厂等
Customize：客制化需求软件制作过程中代码的修改
内容完整要求：SVN提交时必须说明该操作的目的，并尽可能的对相关的实现方法或注意事项进行说明；要尽量详细、清晰的说明修改内容，不允许为空或仅使用“Fix、Mofidy”等简单字词进行备注；
其他要求：为便于检索、跟踪，推荐在注释的内容中尽可能多的包括功能特性相关的模块或特性名称
5.2 SVN提交要求
代码的提交遵循如下的规则：
1、供应商提供的代码：需在代码提交时注明对应的供应商，以及该代码支持的硬件情况进行
第 4 页共5页
SVN提交规范文件编号：
说明，并尽可能对重点特性简要说明，如“11n”、“WAPI”
svn –m “Vendor: Broadcom | 注释”……
2、新特性的开发提交的代码：是指开发阶段的代码提交，提交要详细注明特性要求，设计或实现的大体原理，相关的注意事项，包括遗留问题等。
可在Develop后面写上新特性的关键词，也可不写
svn –m “Develop | [模块名] + 注释”……
3、问题修改的代码提交（bug）：提交中需写明对应的bugFree编号，并对问题简要描述、问题
的解决方法简要描述，同时要说明注意事项
svn –m “Bug: xxxxxxx, xxxxxxx, ……| [模块名] + 注释”……
其中xxxxxxx为对应的BugFree编号；如果一处修改同时改好多个bug，则同时写上多个
BugFree编号。
要求修改一个bug，提交一次，禁止将几个可分开的问题修改合并在一起提交。
4、客制化代码提交：提交中需写明对应的客户、出货的地点；并对客户的主要需求做简要说明。
有的客制化也会涉及客户提到的新特性要求，则新特性的实现按第2点进行单独提交。
svn –m “Customize | 注释”……
5、禁止代码的随意更改，对一个特定项目，不允许改动一个问题，分多次提交SVN
对于注释，参照5.1的规范要求
5.3 SVN提交流程
针对开发代码提交以及问题修改的代码提交要遵循如下的流程：
1、先在工作目录进行开发、调试、修改
2、同步编译目录的代码到SVN服务器上的最新版本
3、将本次要提交的修改内容从工作目录合入到编译目录
4、编译目标代码并进行验证测试
5、将改动内容合入到SVN
6、（可选）从SVN重新下载包含本次改动的代码，进行编译、验证
其他要求：
1、工作目录也要及时更新，不要和SVN服务器有太大的差别
2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交
6、补充说明
1.SVN提交过程中涉及的其他内容，参阅公司相关发布文件。
第 5 页共5页。