版本控制工具使用规范.
版本控制与code review规范
目录
branch使用规则 (3
公共branch命名示例 (3
个人branch命名示例 (3
个人branch创建规则 (3
代码提交流程 (3
Windows平台文件夹方式操作与建议 (4
个人branch创建操作 (4
个人branch代码提交 (6
merge操作 (9
操作步骤1:合并branch (9
操作步骤2:解决冲突 (12
Eclipse 插件方式操作与建议 (14
Mac平台操作与建议 (21
1.采用CornerStone客户端进行SVN操作 (21 1、与服务器创建连接 (21
2、个人branch创建操作 (22
3、把服务器上个人branch 进行check out 到本地 (24
4、个人branch提交(commit操作 (25
5、merge操作 (26
2.采用终端命令提示符进行SVN操作 (28
1、将文件checkout到本地目录 (28
2、往版本库中添加新的文件 (29
3、将改动的文件提交到版本库 (29
4、加锁/解锁 (29
5、更新到某个版本 (29
6、查看文件或者目录状态 (30
7、删除文件 (31
8、查看日志 (32
9、查看文件详细信息 (32
10、比较差异 (32
11、将两个版本之间的差异合并到当前文件 (34
12、SVN 帮助 (35
13、版本库下的文件和目录列表 (35
14、创建纳入版本控制下的新目录 (36
15、恢复本地修改 (36
16、代码库URL变更 (36
17、解决冲突 (37
18、输出指定文件或URL的内容。 (37
branch使用规则
公共branch命名示例
branch-20150326-candidate
个人branch命名示例
branch-20150326-hulanlan
branch-20150326-taskID
个人branch创建规则
●开发人员基于每个开发小任务创建自己的branch, 以每天check in 自己的代码作备份。
●基本原则是从最新代码创建branch,以方便未来的代码合并
●原则是不直接在服务器上操作
代码提交流程
1.测试本地代码
2.整理本地代码, 申请code review
3.提交本地代码到个人branch
4.给目标branch加锁
get lock (目标branch
5.merge个人branch到目标branch
6.测试merge后的目标branch代码
7.提交merge后代码到目标branch
8.给目标branch解锁
Windows平台文件夹方式操作与建议个人branch创建操作
前提:收到任务及编号
操作步骤:
1, 在本地最新代码branch所在目录上点击"TortoisSVN -> Branch/tag" , 如图:
2, 在弹出的窗口中输入相应信息:
注意:
●检查From URL 对应在值为最新目标branch 地址●TO Path 输入您的新branch 名称
3, 点击OK后将发现新branch已经在服务器上创建成功, 现在就可以checkout 到本地干活了。
checkout代码到本地
个人branch代码提交
1、检查新增代码文件新增、删除是否正确操作
描述:打开项目所在的文件夹,右击TortoiseSVN——Check for modfications,弹出如下图窗口。
新增代码文件未加入版本控制时有non-revisioned提示, 如图:
没有通过svn操作而直接进行删除会有missing file 提示,如图:
2、将未加入版本控制的文件加入版本控制
描述:对于non-versioned的文件(除自动生成的文件外,找到其所在的位置,执行add 操作。
加入版本控制操作
正确的svn删除操作:
3、提交代码到自己的branch
描述:打开项目所在的文件夹,右击SVN Commit,弹出如下图窗口,输入本次提交的功能描述后,点击Ok就将代码提交到自己的branch中。
注意:
●这里是提交代码到个人branch, 所以code review 不是必须的。
●不要提交生成文件
代码提交前可以双击文件查看变更,如图:
merge操作
示例任务:
把最新branch的代码
(http://192.168.0.165/svn/amoby-android/branches/branch-20150325-hulanlan
合并到个人branch
(http://192.168.0.165/svn/amoby-android/branches/branch-20150330-taskid_zhou 任务的假设
本地项目文件夹为myproject 且本地文件均已经submit到个人branch中
注意:
如果是merge代码到公共branch, 需要对目标branch执行lock操作,代码提交成功后执行release lock操作
此处定义在merge操作并不是代码提交前应做的完整merge流程.
操作步骤1:合并branch
右击本地项目文件夹myproject,选择SVN checkout——Merge:
选择Merge操作后弹出如下图窗口,这里可以选择默认merge type,然后点击Next
界面中的URL to merge from 中为最新branch的URL,这里可以手工输入或选择路径。选择next,
这里可以直接点击Merge 按钮
如果发现冲突,会有如图红色标记. 否则会提示合并操作完成。
操作步骤2:解决冲突
merge后有冲突会自动弹出如下窗口,如图
●如果已知本地项目中的文件为最新,点击"Prefer local"
●如果已知目标branch中的文件为最新,点击"Prefer repository"
●如果无法简单确认使用哪个文件,则点击"Edit conflict"进行手工合并操作
选择resolve conflict,会弹出文件内容比较窗口
●上方两个小窗口分别对应两个branch中的冲突的文件
●下方小窗口为合并后的文件
●红色为代码冲突部分
解决完后点击save进行保存,关闭些窗口
合并文件后需要点击save进行保存并关闭窗口,会发现如图的“Resolved”按钮可用了
点击resolved后就完成了一个冲突文件的处理。如果有多个冲突文件,则这里将一个文件一个文件地处理。
Eclipse 插件方式操作与建议
1.在eclipse中,从show view里调出SVN资源库视图
2.在SVN资源库窗口的空白位置右键选择新建资源库位置
公司软件管理规范
XXXXXX有限公司 文件制订（修订、作废）申请单NO.: 表格编码：
1. 目的 为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序： 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软
件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表： 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）
田中HW13710专用工具使用说明书
重汽HW系列变速箱维修专用工具 使用说明书 济南田中工贸有限公司 JINAN TIANZHONG GONGMAO CO.,LTD
1. 省力板手(TZ300301) 变速箱输出凸缘螺母（规格S=60mm ）是以1200牛顿·米的大扭矩上紧的。因此在维修需拆卸和上紧该螺母时，即使用加力杠杆也是十分困难的，特别是在整车现场进行拆卸时，就更加困难。如图1，凸缘螺母省力板手是由增扭器、支架、套筒和滑杆滑头以及短加力杆组成。增扭器是一个1比14的行星齿轮增扭器，即输入1牛顿·米的扭矩即可输出4.5牛顿·米的扭矩。如图2，首先将S=60mm 的凸缘套筒头（TZ300314）套在凸缘螺母上，然后用两只凸缘螺栓将支架与凸缘联接固定，再将增扭器输出端和机壳六方同时插入套筒头和支架内，然后用滑杆、滑头和短加力杆旋松或旋紧增扭器的输入端，凸缘螺母即可轻松地旋松或上紧。 图1a. 凸缘螺母省力板手 图1b. 用省力板手拆.装凸缘螺母 图1. 凸缘螺母省力板手 图2. 用省力板手拆、装凸缘螺母 2. 副箱吊盘(TZ300302) 图1是副箱吊盘。在维修解体变速箱以及将主、副箱分离时使用吊盘是十分方便的。 在解体变速箱前，首先用省力板手将凸缘螺母拆卸，然后将输出轴孔内的油封堵头拔出，再用长接杆套筒将输出轴孔内的定心螺帽拆出，再将凸缘螺母重新装上。 如图2b ，用两只凸缘螺栓将吊盘和变速箱输出凸缘联接固定。用吊机将变速箱总成立置。（注意：在将变速箱立置时，要用木块将离合器壳垫起，使输入一轴悬空，以免损坏一轴）。 如果要拆卸副箱，则首先将副箱与主箱联接螺栓拆卸，并确认输出轴中心孔内的定心螺母已经拆卸（这点十分重要，如果输出轴内的定心螺母没有事先拆卸，副箱和主箱的分离是不可能的）。然后用两只M10的顶丝将副箱总成从主箱壳体上分离，如图3，用吊机吊盘将副箱总成与主箱分离。 图1 副箱吊盘 图2. 用吊盘将变速箱总成吊起
svn版本控制工具
第1节背景及svn简介 svn是subversion 缩写，它是一个自由、开放源码、多用户的版本控制系统, 支持通过本地或远程访问数据库和文件系统存储库。Subversion 管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository) 中。这个档案库很像一个普通的文件服务器，不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本，或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。 版本控制是管理数据变更的一种技术。对于程序员来说，它已经成为不可或缺的工具，因为他们经常修改软件代码，产生部分的变更，然后第二天再取消所有的变更。想象有一群程序员同时工作的情况你就能理解，为什么需要一个良好的系统来管理可能出现的混乱。 SVN 不但提供了常见的比较、合并、标记、提交和分支功能，SVN 还增加了追踪移动和删除的能力。此外，它还支持非ASC Ⅱ文本和二进制数据、原子性提交、HTTP 访问等特性，当SVN 被广泛使用时，也需要有个管理工具能够更方便安全地维护SVN 的用户、组、权限、库等内容，协助普通用户更好地配置管理SVN，而无需都交由可能比较繁忙的系统管理员维护。而基于Web 的Subversion 管理工具将是一种非常适合的选择。SVN 可以支持windows 和Linux 两种操作系统，在两种操作系统上运行都具有稳定性和安全性。
SVN 在设计上包括了一个抽象的网络层，这意味着SVN 的版本库可以通过各种服务器进行访问，而允许程序员为客户端“版本库访问”的API 写出先关协议的插件，理论上讲，SVN 可以使用无限数量的网络协议，目前提供了有两种服务器运行方式：一种是Subversion Standalone Server。即svnserve，一个小型的独立服务器，另一种是基于Apache Http Server，即Web 服务器，它通过mod_dav_svn 模块，客户端使用WebDAV/DeltaV 协议进行访问。 SVN站在更高层次上对现在的安全产品，从系统和控制的角度进行了"有机"和"无隙"的整合。 SVN是一个安全虚拟网络系统，它将系统整体的信息安全功能均衡合理地分布在不同的子系统中，使各子系统的功能得到最大限度的发挥，子系统之间互相补充，系统整体性能大于各子系统功能之和，用均衡互补的原则解决了"木桶原理"的问题。 SVN能在跨接Internet, Intranet, Extranet间的网络所有端点实现全面的安全，而且还能提供基于企业策略的信息管理机制以充分有效地利用有限的带宽。SVN可以满足各种企业VPN的要求，通过为公司内部网络、远程和移动用户、分支机构和合作伙伴提供基于Internet的安全连接。所以，我们可以将SVN看成是VPN、防火墙、基于企业策略的信息管理软件集成在一起的Internet安全的综合解决方案。在这样一个网络系统中，所有互联网服务器端和客户端都是安全的，并有一个信息管理机制以不断地通过这个外部网络环境动态地分析及满足客户的
软件版本管理规定
上海精佑通信技术有限公司企业标准 （管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施
上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)
上海精佑通信技术有限公司 文档版本变更记录： 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版 本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射 频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。
C制图常用工具使用方法
C制图常用工具使用方 法 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-
选择工具栏要勾选的几个选项。左下角显示模式： 1、矩形 选择工具，出现： ， 点击起始点后出现：（注意命令提示，一般常用命令为D） 输入’d’: 随后出现： 输入具体值 输入具体值 随后出现 有四个方向可选。 2、扩边、平移、线宽 扩边：首先选中图形，选择偏移工具 输入偏移数值： 选择偏移方向（外偏移、内偏移）： 点击右键确认。 平移： 首先选中图形，选取平移工具，制定基点（相对不动的点）： 挪动鼠标，虚线图形随鼠标移动，到合适位置后点击鼠标左键完成。
线宽选择： 选择图形，点击下拉菜单： 选择合适线宽即可。 3、标柱 首先设置标柱样式： 出现对话框： 选择修改项，修改其内容 修改完成后确定。在需要标柱图形左起始点，点击 在需要标柱图形右结束，点击 松开鼠标，向上滑动鼠标，到合适位置点击左键。 4、缩放 选取图形，选择工具，首先选择基点，图例将矩形右下角为基点，
滑动鼠标， 注意左下角文字说明 比较直观的缩放方法是选择“r”命令 在图形下发点击左键，出现： 再滑动鼠标出现 点击左键，出现图形： 缩放到合适大小后点击鼠标左键。 5、旋转 选择图形，点取工具，制定基点 移动鼠标 6、圆弧 选择工具，选择起点 选择第二个点 命令参数有： 一般画门的时候可应用，例如： 7、打断 选择工具： 8、带基点复制 选择图形，后标题栏中选取： 制定基点，基点可根据实际情况选取。 例如以左下角为基点： 移动鼠标，鼠标中心点即为图形的坐下角，后粘贴：将鼠标靠近原图型，
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
(完整版)技术部软件版本管理规范
技术部软件版本规范 文档建立/修改记录： 版本管理规范 【新建项目版本管理部分】 1，项目组接到项目需求， 1.1，开发组出项目设计和开发计划； 1.2，测试在Git中建立空项目(项目名称开会时候会有，没有需要问)，形成master版本，版本设定为V0.0.0。 2，组长发邮件给技术总监，并且抄送给项目经理和测试。 邮件内容：开发计划文档url和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包含)开发。 3，得到批准开发回复后，测试从master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的更新权限，并且将url给组长。 4，组长download项目，上传项目可运行框架，并且更新GIT中的readme文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中，并且push前必须测试，保证代码不能有运行异常，导致无法测试 5.1，Push结束后，开发者继续开发下一个功能点。 5.2，push结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug文档和测试用例文档的内容(有无bug都需要更新)，随即打开更新权限并通知组长。 6，开发者下一个功能点提交时，同上要求。 7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长，继续进行测试最后一个功能点bug。8，组长通知组员进行bug（bug一般会比较少，bug很多只能说明开发者开发质量有问题）修改，给出修改版本地址。 9，修改完毕后提交，测试人员再次关权限且测试，如仍然有bug存在，更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2)，随即给出版本url给组长。ps：提交版本如有冲突找组长调节。 10，第一阶段开发完全完成后开始开发第二阶段任务，重复2~9步骤，相应的版本号会变为从V0.2.0开始，同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11，当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是V0.x.x，x为任意数字)合并到master版本中，此时版本号设定为V1.0.0。测试发邮件给
项目软件版本号管理规范
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明 如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。
Subversion版本控制工具
Subversion SVN版本控制工具 准备工作： ·Setup-Subversion-1.6.5→服务端软件 ·TortoiseSVN-1.6.6.17493-win32-svn-1.6.6→客户端 ·subeclipse-site-1.6.5.zip→eclipse插件 在开始学习之前你必须要准备好这几个软件； 首先安装SVN的服务端Setup-Subversion-1.6.5，版本不一定要一样，只要是Subversion就可以了，可能会有些差别； ·双击安装包，出现如下界面， ·下面的步骤可以一路Next， 到此就算安装完成了，点击finish，结束安装； ·path命令其实在安装完成之后就已经自动配置好了，所以不需要你去配置了，直接打开cmd 终端，开始创建我们开发用的仓库，也就是版本控制的一个工作空间，可以这么理解；
·打开上面这个界面，我想大家都比我清楚的多了，那我们就用下面的命令创建一个仓库，svnadmin create d:\subversion 这个命令就创建了一个在d盘上的仓库，svnadmin create 命令表示创建一个新的空的版本库，后面的路径就是你版本库所在的位置；执行完命令出现如下的界面说明空的版本库已经创建好了，我们打开D盘看下是不是有一个subversion的文件夹，如果有的话，说明空库创建没问题； ·subversion这个文件夹下有如下的几个文件夹 conf 存放版本库配置文件 db 版本数据存储目录 hooks 存放版本库子目录 locks 存储库锁目录，用来跟踪库的访问者 format 存储一个整数的文件，此整数代表库层次结构版本 readme 这个就是一些简介了 ·我们必须要了解的目录是conf目录及下面的三个文件了 authz 权限配置文件，可以说是svnserve的授权文件
软件版本管理规范19726
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书
需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA
软件版本管理规范标准
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：
【通用】软件版本管理办法.doc
信息系统软件版本管理办法
第一章总则 第一条为加强软件版本管理，规范软件版本管理工作流程，提高版本运行维护质量，保证信息系统安全可靠高效地运行，特制定本办法。第二条本办法涉及的软件包括在线运行的软件和拟投产的软件。软件版本管理对象包括应用软件版本以及相关操作系统、数据库、中间件等基础软件。 第三条软件版本管理是信息系统开发管理和日常维护管理工作的一个重要组成部分，本办法作为软件版本管理的重要依据，软件版本管理归口管理部门、业务支撑部门、风险管理部门、内审部门及各软件供应商要认真履行各自职责，严格执行软件版本管理的各项流程和规定，保障信息系统的安全稳定运行。 第四条任何未经版本归口管理部门许可的软件版本不允许在生产环境使用。在商务合同中若涉及信息系统软件版本，应确认为版本归口管理部门允许使用的软件版本。因使用未经许可的软件版本而造成系统故障影响正常业务交易，相关部门及各厂商要承担相应的责任。第五条本办法由信息技术部负责解释和修订，自发文之日起开始执行。
第二章组织与职责 第六条软件版本管理实行总行集中管理体系。 第七条信息技术部是信息系统软件版本的归口管理部门。 第八条稽核监控部是信息系统软件版本管理的内审部门。 第九条风险管理部是信息系统软件版本管理的风险控制部门。 第十条信息系统软件版本管理工作还涉及软件提供商，软件提供商包括软件最终提供商、代理商和维保服务商（以下简称厂商）。 第一节归口管理部门职责 第十一条归口管理部门负责制定和完善的软件版本管理办法。 第十二条归口管理部门负责制定信息系统软件版本管理工作的工作计划、工作要求和技术规范，并组织实施。 第十三条归口管理部门负责审批业务支撑部门上报的版本变更申请，组织进行资料审核和上线测试，安排试运行工作及全行推广实施。第十四条归口管理部门负责建立软件版本信息库，发布软件版本管理各类信息；建立版本预警体系，发布软件版本缺陷信息和版本预警信息。 第十五条归口管理部门负责与业务支撑部门、风险管理部门、内审部门、厂商协调信息系统软件版本管理的相关工作。 第三节业务支撑部门职责 第十六条版本管理业务支撑部门负责业务类需求的日常收集和集中
定向方法与定向专用工具介绍
根据测斜仪器的种类不同，分为四种定向方式： 1．单点定向 此方法只适用造斜点较浅的情况，通常井深小于1000米。因为造斜点较深时，反扭角很难控制，且定向时间较长。施工过程如下： （l）下入定向造斜钻具至造斜点位置（注意：井下马达必须按厂家要求进行地面试验）。 （2）单点测斜，测量造斜位置的井斜角，方位角，弯接头工具面； （3）在测斜照相的同时，对方钻杆和钻杆进行打印，并把井口钻杆的印痕投到转盘面的外缘上，作为基准点； （4）调整工具面（调整后的工具面是：设计方位角十反扭角）。锁住转盘、开泵钻进； （5）定向钻进。每钻进2～4个单根进行一次单点测斜，根据测量的井斜角和方位角及时修正反扭矩的误差，并调整工具面； （6）当井斜角达到8～10度和方位合适时，起钻换增斜钻具，用转盘钻进。在单点定向作业中要注意：
①在确定了反扭角和钻压后，要严格控制钻压的变化范围，通常在预定钻压±19.6千牛（2吨）内变化； ②每次接单根时，钻杆可能会转动一点，注意转动钻杆的打印位置至预定位置； ③如果调整工具面的角度较大（＞90度），调整后应活动钻具2～3次（停泵状态），以便钻杆扭矩迅速传递。 2．地面记录陀螺（SRO）定向 在有磁干扰环境的条件下（如套管开窗侧钻井）的定向造斜，需采用SRO定向。这种仪器可将井下数据通过电缆传至地面处理系统，并显示或用计算机打印出来，直至工具面调整到预定位置，再起出仪器，施工过程如下： （l）选择参照物，参照物应选择易于观察的固定目标，距井40米左右； （2）预热陀螺不少于15分钟，工作正常才可下井； （3）瞄准参照物，并调整陀螺初始读数； （4）接探管，连接陀螺外筒，再瞄准参照物，对探管和计算机初始化； （5）下井测量，按规定作漂移检查； （6）起出仪器坐在井口，再次瞄准参照物记录陀螺读数； （7）校正陀螺漂移，确定测量的精度； （8）定向钻进。 3．有线随钻测斜仪（SST）定向 造斜钻具下到井底后，开泵循环半小时左右，然后接旁通头或循环接头。把测斜仪的井下仪器总成下入钻杆内，使定向鞋的缺口坐在定向键上。定向造斜时，可从地面仪表直接读出实钻井眼的井斜、方位和工具面，司钻和定向井工程师要始终跟踪预定的工具面方向，保持井眼轨迹按预定方向钻进。 4．随钻测量仪（MWD）定向
几个版本控制软件的比较
几个版本控制软件的比较 https://www.wendangku.net/doc/594731198.html,/bbs/view6-6090-1.htm 一、Visual Source Safe(简称VSS） VSS是美国微软公司的产品，目前常用的版本为6.0版。VSS是配置管理的一种很好的入门级的工具。 易学易用是VSS的强项，VSS采用标准的windows操作界面，只要对微软的产品熟悉，就能很快上手。VSS的安装和配置非常简单，对于该产品，不需要外部的培训（可以为公司省去一笔不菲的费用）。只要参考微软完备的随机文档，就可以很快的用到实际的工程当中。 VSS的配置管理的功能比较基本，提供文件的版本跟踪功能，对于build和基线的管理，VSS的打标签的功能可以提供支持。VSS提供share（共享)、branch(分支）和合并（merge)的功能，对于团队的开发进行支持。VSS不提供对流程的管理功能，如对变更的流程进行控制。VSS不能提供对异地团队开发的支持。此外VSS只能在windows平台上运行，不能运行在其他操作系统上。VSS的安全性不高，对于VSS的用户，可以在文件夹上设置不可读，可读，可读/写,可完全控制四级权限。但由于VSS的文件夹是要完全共享给用户后，用户才能进入，所以用户对VSS的文件夹都可以删除。这一点也是VSS的一个比较大的缺点。 VSS没有采用对许可证进行收费的方式，只要安装了VSS，对用户的数目是没有限制的。因此使用VSS的费用是较低的。 由于VSS是微软的产品，可以得到稳定的技术支持。 二、Concurrent Version System(简称CVS) CVS是开发源代码的配置管理工具，其源代码和安装文件都可以免费下载。 CVS是源于unix的版本控制工具，对于CVS的安装和使用最好对unix的系统有所了解能更容易学习，CVS的服务器管理需要进行各种命令行操作。目前，CVS的客户端有winCVS的图形化界面，服务器端也有CVSNT的版本，易用性正在提高。 CVS的功能除具备VSS的功能外，还具有： 它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码；它的无限制的版本管理检出(checkout：注1)的模式避免了通常的因为排它检出模式而引起的人工冲突；它的客户端工具可以在绝大多数的平台上使用。同样，CVS也不提供对变更流程的自动管理功能。 一般来说，CVS的权限设置单一，通常只能通过CVSROOT/passwd, CVSROOT/readers, CVSROOT/writers文件，同时还要设置CVS REPOS的物理目录权限来完成权限设置，无法完成复杂的权限控制；但是CVS通过CVS ROOT目录下的脚本，提供了相应功能扩充的接口，不但可以完成精细的权限控制，还能完成更加个性化的功能。 CVS是开发源码软件，无需支付购买费用。 同样因为CVS是开发源码软件，没有生产厂家为其提供技术的支持。如发现问题，通常只能靠自己查找网上的资料进行解决。 三、StarTeam StarTeam是Borland公司的配置管理工具，StarTeam属于高端的工具，在易用
软件版本管理规定
软件版本管理规定 文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-
广东亿迅科技有限公司 软件版本管理办法（暂行） 第一章总则 第一条为了加强广东亿迅科技有限公司（以下简称“公司”）的软件版本管理工作，进一步细化公司配置管理规范，建立软件版本管理的规范化操作流程，保证公司软件产品质量，制定本办法。 第二条本办法适用于公司各技术部门的软件版本管理工作。 第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。 第四条软件版本（以下简称“版本”）管理应遵循以下原则： (一)实施版本变更应符合以下原则之一： 1.为满足客户新业务、新功能需求； 2.为满足提高业务质量、提升业务性能指标和容量扩充的需求； 3.为解决软件故障和软件稳定性、安全性、可控性问题； 4.为了提高软件可维护性。 (二)版本的集成和发布应严格按照计划执行，避免随意和频繁更新版本; (三)为保证软件质量，任何一个软件版本须通过版本测试后方可上线； (四)公司所有软件版本必须通过正式渠道发布给用户，未经审批各部门和个人不得擅自向用户发布软件版本。 第五条版本管理是保障应用软件正常运行的一个重要手段，各相关部门应认真贯彻落实，并纳入工作考核；未按本办法执行从而造成版本故障影响用户正常生产的，一经发现将追究其相应责任。 第二章职责与分工
第六条版本管理实行总体质量控制，分级实施管理原则，管理工作涉及版本质量管控部门和版本集成发布部门；质量管理部是版本质量管控部门，各业务部门是版本集成发布部门。 第七条版本质量管控部门的工作职责如下： (一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实； (二)负责组织版本管理相关的培训并提供技术支持； (三)负责跟踪和监督公司版本管理工作的执行情况，协调解决执行中的问题，并对版本管理的执行效果进行评估考核； (四)负责组织和实施对版本的测试验证工作； (五)负责对版本升级实施效果和版本质量进行监控和评估； (六)其它应由版本质量管控部门负责的事项。 第八条版本集成发布部门的工作职责如下： (一)负责本部门版本研发集成工作环境的建立、维护和管理； (二)负责依据版本管理工作流程，执行版本开发、集成、发布及维护的相关工作； (三)负责收集分析业务需求，制定版本计划并按计划组织实施； (四)负责跟踪版本上线后的运行情况，收集用户使用的反馈信息，改进版本质量； (五)其它应由版本集成发布部门负责的事项。 第九条版本质量管控部门设置专职版本管理工程师和测试工程师岗位，负责版本的质量管控及流程监督；版本集成发布部门应在各项目组内设置专职或兼职版本管理员，负责本项目版本集成发布的具体工作。 第三章版本管理 第十条版本管理的各项工作应按照本办法规定的流程和要求执行。版本集成发布部门可以根据本办法的要求结合项目实际情况，对工作流程进行进一步细化。
常用工具简介及使用说明
常用工具简介 及使用说明 安 阳 小 学 一．木工锯1.简介
木工锯，也称锯子，是木工工匠们在加工木材时使用的工具之一。一般可分为框锯、刀锯、槽锯、板锯等。 2.分类 框锯 又名架锯，是由工字形木框架、绞绳及绞片、锯条等组成。锯条两端用旋钮固定在框架上，并可用它调整锯条的角度。绞绳绞紧后，锯条被绷紧，即可使用。框锯按锯条长度及齿距不同可分为粗、中、细三种。粗锯锯条长650—750mm，齿距4—5mm，粗锯主要用于锯割较厚的木料；中锯锯条长550—650mm，齿距3—4mm，中锯主要用于锯割薄木料或开榫头；细锯锯条长450—500mm，齿距2—3mm，细锯主要用于锯割较细的的木材和开榫拉肩。 刀锯 刀锯主要由锯刃和锯把两部分组成，可分为单面、双面、夹背刀锯等。单面刀锯锯长350mm，一边有齿刃，根据齿刃功能不同，可分纵割和横割两种；双面刀锯锯长300mm，两边有齿刃，两边的齿刃一般是一边为纵割锯，另一边为横割锯。夹背刀锯锯板长250—300mm，夹背刀锯的锯背上用钢条夹直，锯齿较细，有纵割和横割锯之分。
槽锯 槽锯由手把和锯条组成，锯条约长200mm。槽锯主要用于在木料上开槽。 板锯 又称手锯。由手把和锯条组成，锯条长约250—750mm，齿距3—4mm，板锯主要用于较宽木板的锯割。 狭手锯 锯条窄而长，前端呈尖形，长度约300—400mm。狭手锯主要用于锯割狭小的孔槽。 曲线锯 又名绕锯，它的构造及框锯相同，但锯条较窄（10mm左右），主要是用来锯割圆弧、曲线等部分。 3.用法 纵割法 锯割时，将木料放在板凳上，右脚踏住木料，并及锯割线成直角，左脚站直，及锯割线成60°角，右手及右膝盖成垂直，
版本控制工具使用规范.
版本控制与code review规范 目录 branch使用规则 (3 公共branch命名示例 (3 个人branch命名示例 (3 个人branch创建规则 (3 代码提交流程 (3 Windows平台文件夹方式操作与建议 (4 个人branch创建操作 (4 个人branch代码提交 (6 merge操作 (9 操作步骤1:合并branch (9 操作步骤2:解决冲突 (12 Eclipse 插件方式操作与建议 (14 Mac平台操作与建议 (21 1.采用CornerStone客户端进行SVN操作 (21 1、与服务器创建连接 (21
2、个人branch创建操作 (22 3、把服务器上个人branch 进行check out 到本地 (24 4、个人branch提交(commit操作 (25 5、merge操作 (26 2.采用终端命令提示符进行SVN操作 (28 1、将文件checkout到本地目录 (28 2、往版本库中添加新的文件 (29 3、将改动的文件提交到版本库 (29 4、加锁/解锁 (29 5、更新到某个版本 (29 6、查看文件或者目录状态 (30 7、删除文件 (31 8、查看日志 (32 9、查看文件详细信息 (32 10、比较差异 (32 11、将两个版本之间的差异合并到当前文件 (34 12、SVN 帮助 (35 13、版本库下的文件和目录列表 (35 14、创建纳入版本控制下的新目录 (36
15、恢复本地修改 (36 16、代码库URL变更 (36 17、解决冲突 (37 18、输出指定文件或URL的内容。 (37 branch使用规则 公共branch命名示例 branch-20150326-candidate 个人branch命名示例 branch-20150326-hulanlan branch-20150326-taskID 个人branch创建规则 ●开发人员基于每个开发小任务创建自己的branch, 以每天check in 自己的代码作备份。 ●基本原则是从最新代码创建branch,以方便未来的代码合并 ●原则是不直接在服务器上操作 代码提交流程 1.测试本地代码 2.整理本地代码, 申请code review 3.提交本地代码到个人branch
软件版本管理表格
XX公司软件版本控制办法 1、目的 规范本公司软件产品版本的升级流程，清晰管理软件版本号，保证各使用人、使用地点的版本软件都能胜任工作，并可靠保存不同版本软件。 2、适用范围 适用于研发结束进行测试或投入应用的软件系统、硬件驱动软件或独立工作软件，已销售产品中的软件系统的升级或变更管理等。 3、职责 3.1版本管理员负责统计公司内所有软件的版本信息，管理软件版本号，向软件工程师传达工程、维护及销售人员反馈的软件问题并进行汇总，在软件升级结束后向系统集成工程师提供新版本的软件系统。 3.2项目软件负责人及软件工程师负责对软件系统进行升级，项目软件负责人负责将升级后的软件上传到公司产品服务器，并通知版本管理员记录升级信息。 3.3每个项目的软件负责人对本小组内目前完成测试的软件及系统进行归档和版本维护。 3.4项目软件负责人对本项目的软件升级方法进行确认，将对软件的整体调整与总工协商后确定方法。 3.5销售人员和工程人员向版本管理员通报软件产品问题，工程人员负责升级后软件的重新安装和使用跟踪，并对修改版本软件的使用情况在规定时间内进行反馈。 3.6工程部集成工程师在完成软件安装后应填写客户版本信息清单，提交版本管 理员进行归档并汇总。 3.7 对于软件系统的一般性BUG和软件实现明显不适当的问题，项目软件负责人应积极进行修改，升级软件版本；其他软件使用性问题，项目软件负责人有权确定是否修改。 3.8对于软件功能性的重大修改，应将问题进行备案，并提交总工程师确定是否修改以及修改时间。对涉及需要产品升级等问题时，应提交公司技术委员会进行讨论确定。 4、工作程序 4.1软件系统保存 4.1.1建立公司产品存储服务器，网管（研发部）为每个项目组分配源代码存储区域，对每
某软件有限公司文档版本管理规范
密级：内控 研发本部版本管理规范 V1.0 浪潮集团山东通用软件有限公司
目录 文档类别使用对象 (2) 1．引言 (3) 1.1目的 (3) 1.2范围 (3) 1.3术语定义 (3) 1.4参考资料 (4) 1.5版序控制记录 (4) 1.6版本更新记录 (4) 2．版本管理 (5) 2．1版本标识方法 (5) 2．1．1正式版本 (5) 2．1．2特殊版本 (5) 2．2目录结构 (5) 2．3文档的存放 (7) 2.3.1 当前版本和历史版本的存放 (7) 2.3.2 开发文档的存放 (7) 2.3.3 源代码的存放 (7) 2.3.4 SQL语句的存放 (7) 2.3.5发行文档的存放 (8) 2．4权限控制管理 (8) 3．更新管理 (8) 3．1源程序的修改 (8) 3．2已发布版本的维护及修改 (9) 3．3外出人员对产品的修改 (9) 3．4版本升级 (12) 3.4.1 版本升级原则 (12) 3.4.2 新版本的发布 (12) 3.4.3 安装盘制作步骤 (13) 4．备份管理 (13) 5．用户版本管理 (14)
文档类别使用对象 文档类别 该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。使用对象 该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言 1.1目的 本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。 1.2范围 本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3术语定义 SCM Softwere Configuration Management缩写 SVM Software Version Management缩写 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确
软件版本管理制度
软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言 .............................................................................. 1.1目的............................................................................. 1.2范围............................................................................. 1.3术语定义......................................................................... 1.4版序控制记录..................................................................... 1.5版本更新记录..................................................................... 2版本管理........................................................................... 2.1流程图........................................................................... 2.2版本命名......................................................................... 2.3版本升级......................................................................... 2.3.1版本升级原则................................................................. 2.3.2新版本的发布................................................................. 2.4目录结构......................................................................... 2.5文档的存放....................................................................... 2.5.1文本文件的存放............................................................... 2.5.2源代码的存放................................................................. 2.5.3发行文档的存放 (9) 2.6权限控制管理..................................................................... 3备份管理........................................................................... 3.1源文件备份....................................................................... 3.2库文件备份....................................................................... 4用户版本管理....................................................................... 5版本工具的使用..................................................................... 5.1配置管理工具..................................................................... 5.2CVS的使用 ....................................................................... 5.2.1常用命令..................................................................... 5.2.2简单操作..................................................................... 5.2.3版本分支管理.................................................................