配置项如何进行版本控制
Ⅰ 分析一下如何进行版本控制
目标:
1)保证各个环境(开发、测试、主干)的独立,避免相互影响;
2)减少最终发布时合并主干出现冲突的概率;
3)降低冲突处理的难度。
原则:
多个版本(开发版本,测试版本,发布版本);
多次合并。产品经理一定要对版本进行把控,不合适了及时更新,不知道什么时候更新多去黑马程序员社区看一些产品经理的知识!
Ⅱ 配置管理流程
制定配置管理计划
配置管理员制定《配置管理计划》,主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
配置库管理
配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库,例如清除垃圾文件、备份配置库等。
版本控制
在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于不能保证新版本一定比老版本“好”,所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
配置项的状态有三种:“草稿”、“正式发布”和“正在修改”,本规程制定了配置项状态变迁与版本号的规则。
变更控制
在项目开发过程中,配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”,无需CCB的批准,修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”,或者被“冻结”后,此时任何人都不能随意修改,必须依据“申请→审批→执行变更→再评审→结束”的规则执行。
配置审计
为了保证所有人员(包括项目成员、配置管理员和CCB)都遵守配置管理规范,质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动,是质量保证人员的工作职责之一。
Ⅲ 如何为VS2010添加版本控制
网络搜索 Visual Source Safe 2005 安装文件,下载并保存。
2,运行setup.exe文件
3,按照步骤执行安装,默认安装配置即可
4,安装完成
5,注意!!!这里要以管理员身份运行Microsoft Visual SourceSafe
6,进入设置向导,点击下一步
7,选择简历一个新的database
8,任意选择一个文件夹来存放数据库数据,点击下一步,然后任意输入数据库的名称
9,选择-Modify-Merge-Model,点击下一步,然后点击完成
10,打开VS2010,选择工具——选项——源代码管理——下来列表中选择(当前源代码管理插件)Microsoft Visual SourceSafe——确定
11,打开现有解决方案,选择文件--源码管理--将解决方案添加到源代码管理,即可
Ⅳ 如何为VS2010添加版本控制
运行setup.exe文件
按照步骤执行安装,默认安装配置即可,安装完成。
注意,这里要以管理员身份运行Microsoft Visual SourceSafe
进入设置向导,点击下一步
选择简历一个新的database
任意选择一个文件夹来存放数据库数据,点击下一步,然后任意输入数据库的名称
选择-Modify-Merge-Model,点击下一步,然后点击完成
打开VS2010,选择工具——选项——源代码管理——下来列表中选择(当前源代码管理插件)Microsoft Visual SourceSafe——确定
打开现有解决方案,选择文件--源码管理--将解决方案添加到源代码管理,即可。
Ⅳ 网站开发时,怎么进行版本控制具体装什么软件,怎么配置
服务器安VisualSVN-Server-2.1.3,客户端安TortoiseSVN-1.6.10.19898-win32-svn-1.6.12,可以把一个人的电脑作为服务器,固定IP就行。
Ⅵ svn在项目开发过程中到底有什么作用呢 怎么叫版本控制呢还有自己可以用它看到别人的代码吗
简单的说,SVN就是把大家的代码集中到一起进行管理,并且把每个历史版本都存起来。
SVN是C/S架构的,所有的代码上传到服务器端统一管理,每个人可以从服务器端随时拿到最新版本的代码(能拿到哪些代码受权限控制),可以在本地客户端新增、修改、删除后再上传到服务器端,形成新的最新版本。
当然了,要讲到版本控制,就必须理解代码基线、分支等概念,这个不是几句话能说清的,建议你看看我的网络文库,里面有篇在Windows环境下使用SVN的PPT,相信你看完后就明白SVN是干嘛的了。
Ⅶ 配置管理和变更管理方法
变更常有
所在银行科技部已经建立了比较完善的项目管理体系和质量保障体系,但要应对分行或支行需求变更和相关软件版本配置管理的问题,如果没有一整套的解决措施和工具的支持,就会出现以下问题:
1)分行反映的缺陷更改不能快速响应,不能快速分配缺陷到指定的开发人员,只能依靠口头或文档的传输,缺乏一个整合开发商服务人员、产品经理(或项目经理)、开发团队领导、开发人员、分行领导的信息传递和交流的平台。
2)分行的需求变更不能快速响应。分行的需求变更和软件版本配置只能依靠手工备份,因而,自身不能快速有效地管理各系统的版本,缺乏版本基线的管理策略。
针对以上问题,可以考虑采用软件配置管理这一关键域的思路系统地解决以上问题。配置管理是整个集成软件项目正常运作的一个管理支撑平台,其目的就是将有关该项目的客户、客户服务人员、产品经理(或项目经理)、开发团队领导、开发人员、高层领导等项目干系人的工作协同起来,实现高效的沟通,及时地共享工作成果。
配置管理的基本功能包括配置标识、变更控制、配置状态发布和配置审计。变更控制是配置管理的重要内容,其目的是为了在动态中保证配置项的完整性、一致性和可回溯性,保证配置项的变更过程规范、受控、有完整记录,受影响的各方均能及时了解情况,并协调一致。
控制不可少
变更控制是通过创建产品基线,在产品的整个生存周期中控制它的发布和变更。配置控制指在配置项标识正式确定之后,对配置项特别是对已提交的代码、相关文档和数据等的变更进行系统地跟踪和控制的过程,主要包括变更的'提出、确定配置项的控制等级、变更的评价、变更的处置、实施经批准的变更、对变更进行验证和结束变更。变更控制的目的是建立一套控制软件修改的机制,保证生产符合质量标准的软件和保证每个版本的软件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作,以确定在变更控制过程中控制什么,如何控制,谁控制变更、何时接收变更、批准和检验。
配置项级别
1)已基线化的配置项是指已完成该配置项的审核和批准,并且成为创建或修改其他配置项的输入。例如:一个设计文档已审核、通过、签发,并且成为编码活动的基础。
2)受管理和受控的配置项是指已提交审核,但还没有批准通过的配置项。例如:一个正在进行审核的设计文档。
3)受控的配置项指已置于版本控制,但项目组不能直接进行改动的配置项。例如:用户提供的软件、购买的工具、产品标准等等。
变更请求的状态
软件变更、软件优化和软件bug都是产生变更的原因。变更申请人(用户或产品经理)提出变更时,首先要对受控的配置项的修改提出一个变更请求,说明对软件变更的需求。这是因为变更控制过程是通过变更请求的流动来实现的,而且对软件的任何请求都必须和相应的变更请求对应。
变更请求的状态包括:
1)提交:变更请求提交给配置管理员;
2)拒绝:变更控制委员会拒绝变更请求;
3)接受:变更控制委员会接受变更请求;
4)挂起:变更请求被挂起,以后再作决定;
5)已验证:更改已执行和验证;
6)关闭:验证并归档配置项,更新的配置项提交给用户(例如:通过版本发布)。
变更请求的类型
1)增强型:变更请求要求对已批准的项目功能进行增强。
2)改进型:变更请求不会造成功能更改,但使配置项的维护更加有效率。
3)纠错型:变更请求对错误进行修正(诸如bug)。
变更请求的优先级
在评价变更请求的优先级时,要对请求变更的配置项进行系统的分析,确定变更影响范围和修改的程度,确定变更的级别,为确定是否有必要记录变更提供参考依据。变更请求的优先级可分为三类:
1)高:严重地影响一些用户或许多用户。
2)中:对用户造成不方便,或是可以采取相应的变通方法处理的主要问题。
3)低:小问题。
修改完后签入(Check in)
对变更的处理,要按照变更控制规程,将变更请求及其相关附件提交软件配置控制委员会审批。配置管理组根据审批意见处理变更请求。
只有配置管理员具有Check in权限。在进行Check in之前,确认下面的事项:
1)所有对配置项所做的修改被批准;
2)所有的更改都经过审核或验证;
3)所对应的变更请求已经被保存起来;
4)所有相关的审核记录被保存;
5)Check in时须注明Check in因,如对应的变更请求。
从数据库中签出(Check out)
1)对于文档,配置管理员在更改审批人同意后,从配置库中Check out配置项,发给项目组成员修改。
2)Check out时须注明Check out原因,如将要修改的问题。
3) 配置管理员一定要在配置状态发布中跟踪被Check out出来的配置项。
Ⅷ 如何使用SVN进行版本控制
Android studio如何使用SVN进行版本控制?
如题,有哪位大神在实际工作中使用了Android studio和SVN的,能说明一下具体的操作吗?下图是我测试SVN时初始化导入到SVN后,本地项目就变成一片红了,然后点击更新也没用;修改了内容后提交时,提示我没有任何修改,无法提交,真真的是郁闷啊!
添加评论 分享
默认排序
按时间排序
25 个回答
161
赞同
反对 知乎用户 Android Studio关联SVN相关操作
161 人赞同 通过这两天对Android Studio的研究,终于搞通了Android Studio的基本操作及与SVN的相关关联操作(这样才能在公司的开发工作中使用);Google年底将会停止ADT插件的更新和支持,全面转向Android Studio(果然是自己的孩子啊),因此使用Android Studio进行安… 显示全部
通过这两天对Android Studio的研究,终于搞通了Android Studio的基本操作及与SVN的相关关联操作(这样才能在公司的开发工作中使用);Google年底将会停止ADT插件的更新和支持,全面转向Android Studio(果然是自己的孩子啊),因此使用Android Studio进行安卓项目的开发也是大势所趋,项目得闲之时研究一下Android Studio的使用;Android Studio的基本编辑操作现在网上已经很多了,需要的可以找着看看,下面是这几天摸索出来的Android Studio关联SVN的相关操作,时间较短,如果有疏漏或错误的地方还望指正。
一、Android Studio配置SVN
Android Studio关联配置SVN很简单,在Settings里面,找到Version Control->Subversion;在这个页面的控制面板中的General中将Use command line client打勾勾选上,然后浏览本地的SVN安装目录,选到"\svn.exe"即可;
在Use command line client下面还有一个Use system default Subversion configuration directory,这个默认是勾选上上的,这个是svn相关配置信息的路径,保留默认路径就行,目前没有发现需要修改什么东西;以上操作如下图:
二、Android Studio项目关联SVN资源库及添加忽略文件
在Android Studio中新创建一个Android项目,成功后我们先来添加要忽略的文件;在Android Studio中添加忽略文件同Eclipse有所不同,在Eclipse上我们什么时候添加忽略文件都可以,但是在Android Studio中只有在未关联SVN之前添加忽略文件才有效(试了好多次才将忽略文件忽略成功啊!)。Android Studio添加忽略文件同样是在Settings->Version Control(跟版本控制有关的设置都在这个目录下)下的Ignored Files里,点击加号进行忽略文件的设置,Android Studio默认给出了三种忽略方式,供开发者进行选择:忽略指定的文件、忽略文件夹下所有文件和忽略符合匹配规则的文件;如图所示:
点击右侧的“+”进行添加,“-”删除;Android Studio创建的Android项目一般需要忽略.idea文件夹、.gradle文件夹、所有的build文件夹、所有的.iml文件及local.properties文件。
忽略完文件后,我们进行项目同SVN的关联,选择VCS->Import into Version Control->Share Project(Subversion);这里说明一点,在Import into Version Control下有Import into Subversion和Share Project(Subversion)两个选项:第一个是直接将项目导入到SVN服务器上,但是这样做本地的项目同SVN服务器没有建立起关联,在导入后项目所有的文件都会变成红色,而且在要提交到SVN服务器时会提示项目不是SVN下的工作副本;第二个是将Android Studio当前项目同SVN服务器关联起来,但是并没有将项目导入到SVN服务器上,需要在完成建立连接后再次提交项目到SVN服务器。两种方式都可以实现将本地代码提交到SVN服务器的功能,但是步骤有所不同,先来完成第二种方式的项目同SVN的关联及代码提交,第一种貌似不正规,之后再说;下图既是第二种方式将本地项目同SVN进行关联的:
之后会弹出选择要分享的SVN地址及其他选项,如下图:
在Define share target下选择第二个可以再trunk下创建你当前项目的文件夹,相应的第一个选项是直接将整个文件都放到trunk文件夹下,第三个在项目文件夹下有创建了一个trunk文件夹,因此建议使用第二中方式;选择完成后点击Share就可以了,会弹出让你选择SVN工作副本的格式化版本(jdk版本),如下图:
建议选择1.8format,我之前选择了其他的试了一下,发现项目总会报出一下错误,原因暂时未发现,就先这样选择吧;点击OK等待一会就能创建本地项目同SVN服务器的关联了;成功后悔自动刷新本地的项目,待项目里的内容变成绿色的即表示已经成功了,如下图所示:
到目前为止只是将项目同SVN服务器建立了联系,并没有将代码提交到SVN服务器上去;如何提交呢,其实很简单,只需点击SVN相关操作按钮里的commit就行了(上图SVN相关操作按钮左起第二个按钮);
点击Commit后Android Studio会先对当前代码进代码分析,如果有错误或者警告会弹出如下的框,如果有错误冲突等需要解决后再提交,如果是警告可以忽略(同Eclipse相同);第一次将整个代码提交到SVN服务器时时间有可能很长,请耐心等待,之后再创建项目时就不会这么慢了。
成功后我们就完成了新建项目同SVN的关联及导入项目到SVN服务器上了。
关于第一种方式,在将本地代码导入到SVN服务器后将本地代码删除,然后从SVN服务器上将之前提交的代码更新下来,这样一来也可以同SVN建立关联正常进行开发;第一种方式和第二种方式的区别就在于:第一种是将代码先提交到SVN服务器上,然后再从SVN服务器上更新下来(本地项目同SVN服务器建立联系);第二种是先同SVN服务器监理联系,然后将代码提交到SVN服务器上去。建议使用第二种方式进行新项目的SVN关联。
三、Android Studio SVN代码冲突的解决
关于代码冲突解决的问题,首先要感谢一下知友ShinChven的回答建议。在使用SVN更新服务器上的代码时,有时会弹出代码冲突的对话框,问你是否进行合并,并提供了三种合并方案:accept yours(使用你的)、accept theirs(使用别人的)和merge(合并);
前两个都是进行的覆盖操作,就不多做解释了;当你选择merge合并时,会弹出代码合并对照窗口,一共有三个屏,左右两侧时你和服务器不同的代码并高亮显示不同的部分,带有箭头和叉号,通过点击箭头将两边冲突的代码添加到中间的合并区域中去,点击叉号则辨识放弃那一段代码,待所有冲突处理完成后merge就成功了。
Ⅸ 如何使用SVN进行版本控制
SVN全名Subversion,即版本控制系统。SVN与CVS一样,是一个跨平台的软件,支持大多数常见的操作系统。作为一个开源的版本控制系统,Subversion管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository)中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本,或是浏览文件的变动历史。Subversion是一个通用的系统,可用来管理任何类型的文件,其中包括了程序源码。
SubVersion:实现服务系统的软件。
TortoiseSVN:是SVN客户端程序,为windows外壳程序集成到windows资源管理器和
文件管理系统的Subversion客户端。
SVNService.exe:是专为SubVersion开发的一个用来作为Win32服务挂接的入口程序。
AnkhSVN:是一个专为VisualStudio提供SVN的插件。
Subversion提供以下主要功能:
目录SVN版本控制
CVS只能跟踪单个文件的历史,不过Subversion实作了一个“虚拟”的版本控管文件系统,能够依时间跟踪整个目录的变动。目录和文件都能进行版本控制。
真实的版本历史
自从CVS限制了文件的版本记录,CVS并不支持那些可能发生在文件上,但会影响所在目录内容的操作,如同复制和重命名。除此之外,在CVS里你不能用拥有同样名字但是没有继承老版本历史或者根本没有关系的文件替换一个已经纳入系统的文件。在Subversion中,你可以增加(add)、删除(delete)、复制()和重命名(rename),无论是文件还是目录。所有的新加的文件都从一个新的、干净的版本开始。
自动提交
一个提交动作,不是全部更新到了档案库中,就是完全不更新。这允许开发人员以逻辑区间建立并提交变动,以防止当部分提交成功时出现的问题。
纳入SVN版本控制的元数据
每一个文件与目录都附有一组属性关键字并和属性值相关联。你可以创建,并储存任何你想要的Key/Value对。属性是随着时间来作版本控管的,就像文件内容一样。
选择不同的网络层
Subversion有抽象的档案库存取概念,可以让人很容易地实作新的网络机制。Subversion可以作为一个扩展模块嵌入到ApacheHTTP服务器中。这个为Subversion提供了非常先进的稳定性和协同工作能力,除此之外还提供了许多重要功能:举例来说,有身份认证,授权,在线压缩,以及文件库浏览等等。还有一个轻量级的独立Subversion服务器,使用的是自定义的通信协议,可以很容易地通过ssh以tunnel方式使用。
一致的数据处理方式
Subversion使用二进制差异算法来异表示文件的差异,它对文字(人类可理解的)与二进制文件(人类无法理解的)两类的文件都一视同仁。这两类的文件都同样地以压缩形式储存在档案库中,而且文件差异是以两个方向在网络上传输的。
有效的分支(branch)与标签(tag)
在分支与标签上的消耗并不必一定要与项目大小成正比。Subversion建立分支与标签的方法,就只是复制该项目,使用的方法就类似于硬连接(hard-link)。所以这些操作只会花费很小,而且是固定的时间。
Ⅹ 关于项目管理中配置管理的实现过程,配置项的知识请教以及相比版本管理的差异
你的理解更多是“产品集成”的概念,即怎么把几个产品模块或构件组合成一个产品,但这不是配置管理的概念。
配置管理:简称CM(Configuration Management的缩写),标识、控制和管理变更的一种管理活动。它控制配置项的修改和发行;记录和报告配置项的状态和变更;保证配置项的完整性、一致性和正确性;以及控制配置项的储存、装载和交付。
根据这个定义,配置管理的主要工作包括:
1)配置库的管理活动。配置库现在工具非常多,例如GIT、SVN、CVS、VSS等等。通常会根据开发所处的阶段,设立开发库、受控库与产品库。
2)标识配置项,即需要定义如何去标识配置项。配置管理中受控制的对象被称为配置项,是生命周期中创建的信息,包含程序、数据、文档,分基线配置项和非基线配置项两类。特别是你的产品最终是如何标识的,比如怎样定义V1.0.0的规则。
3)基线的管理。是一组经过正式审查并且达成一致的规范或工作产品,是下一阶段工作的基础。怎样确定、发布基线,怎样管理基本的变更。
4)配置项变更管理。可以根据不同的配置项、不同的开发周期,明确变更的管理规则。
5)配置项状态管理与配置审计 。
而产品集成是如何把一个产品逐步的从一个个模块或组件,最后组合成一个产品的过程。
1)首先产品的技术结构上要能够支持,如果模块不能相互独立和拆解,谈不上灵活的组合。
2)在开发实现上,需要有一个集成的策略,哪些先实现,哪些后实现,哪些可以先进行集成
3)需要建立 集成的环境,使开发好的模块可以在集成环境中进行调试
4)通常开发完成后,需要进行源代码的编译,并打包成一个测试包,然后装在集成环境中,进行调试,以确认各个模块之前是否可以兼容和运转,这时通常会进行测试工作。
5)如果你想进行ABC组合,或者AC组合,那么都需要进行相应的编译、打包(例如形成EXE)过程,然后在集成环境中进行联调和测试。