软件版本控制（通用5篇）
软件版本控制 篇1
0 引言
随着信息技术的发展,目前部队指挥信息系统中各指挥终端已不是独立工作,而是网络化、分布式、协同工作。但是对于系统软件和应用软件的安装,目前我们还处在技术人员逐台对指挥终端进行软件部署的阶段。这样就面临着如下问题:(1)难以全面地掌握指挥所本地网络中所有指挥终端的软件安装现状;(2)安装过程中容易因为人员疏忽某步骤或文件导致各种系统故障,难以快速准确地更新各终端的应用软件;(3)当发现问题并解决问题或发布应用软件更新,难以避免机械的重复劳动;(4)安装或更新出问题或软件版本不统一,容易造成终端上应用软件不能正常运行,严重时甚至影响整个指挥系统的正常运行。
由此可见,对指挥信息系统的应用软件版本进行控制管理十分必要。我们对应用软件版本控制管理已进行初步研究,通过研究一套版本控制软件来解决这些问题。
1 版本控制软件设计
1.1 基本功能
版本控制软件应具备以下功能:(1)系统首次安装时,通过某一管理终端对普通席位进行快速发布;(2)当应用程序或配置文件更新时,自动将所要更新的文件及时地发布到各席位;(3)记录应用程序安装、更新版本的历史过程,防止随意修改应用程序版本并为问题回溯提供依据。
1.2 基本组成
版本控制软件由下列4部分组成:版本控制服务器端软件、版本更新服务器端软件、版本更新客户端软件、远程安装发布服务器端软件。其中,应用程序发布服务器端软件运行于Windows平台管理席位,版本更新服务器端软件运行于UNIX服务器,版本更新客户端软件运行于Windows平台普通席位。版本更新客户端软件是随应用程序在系统首次安装时由安装发布服务器端软件安装到各个席位[1]。版本控制软件结构如图1所示。
版本控制软件能够对用户上传的文件(需要将更新的应用程序或配置文件上传到指定的目录中)进行发布和控制,但是对于此外的文件(用户在客户端修改的文件不在服务器指定上传目录中)将不作监控。
版本控制软件工作流程如图2所示,有两种情况。
情况之一:
流程1:服务器端软件定时在局域网内发送广播报文,报文内容由文件更新列表的唯一标识和时间戳组成。
流程2:客户端软件接收到广播报文后,将报文中文件更新列表的唯一标识和时间戳与本地保存的信息进行对比,当两者有所区别时,客户端向服务器端发送报文,请求获得新的更新文件列表。
流程3:服务器端接受请求,并向客户端发出更新文件列表(包括需要更新的文件数量、名称、位置、大小、校验值等信息)。
流程4:客户端经过对比更新文件列表中文件信息与本地对应文件信息,生成实际需要发送的文件列表,并且将列表发送到服务器端。
流程5:服务器接受列表,建立文件发送过程。
情况之二:
客户端软件定时将本地上一次更新的文件列表中的文件与实际文件信息进行对比,当文件信息不一致时,直接进入流程4。
1.2.1 版本控制服务器端软件
版本控制服务器端软件主要完成4个任务:广播更新信息,本地文件管理,客户端管理连接,日志功能。
(1)广播更新信息:定时在指挥所内局域网上广播本地需要更新的文件信息,广播报中内容包括文件列表的唯一标识符和时间戳。当文件有更新的时候,立即开始定时广播报的重新计时,并发出包含新内容的广播报文。
(2)本地文件管理:对本地指定上传目录中的文件进行定时扫描,一般在第一次扫描后即把文件的名称、大小、位置、CRC校验值等信息记录下来。随后每次扫描都将结果与上次扫描进行对比(对比上面提到的所有信息),如结果一致则等待下次扫描,如结果不一致则重新生成文件信息记录和文件更新列表,并通过广播通知客户端有文件更新。
(3)客户端管理:客户端管理用于响应客户端的各种请求,包括:发送当前更新文件列表;根据客户端的实际情况,准备实际文件发送列表(因为在服务器端,可能只更新了某几个文件),并将这些文件发送到客户端。
(4)日志功能:日志功能主要记录以下信息:服务器端每次文件更新的时间、文件名称、文件大小、文件校验值、文件位置等信息。客户端更新文件的历史记录包括客户端地址、更新时间、文件名称、文件大小、文件校验值、文件位置等信息。
1.2.2 版本更新服务器端软件
版本更新服务器端软件由本地文件处理、过程记录、客户端管理、前台服务组成,如图3所示。
图3版本更新服务器端软件组成
本地文件处理主要完成下面的任务:
(1)定时扫描指定的上传目录,通过递归扫描的方式,将文件的位置、文件的名称记录下来。在扫描的同时计算出这些文件的大小和CRC校验值。因此用户如果需要更新软件或配置文件,就需要按原目录路径将应用程序和配置文件上传到指定的上传目录。
(2)将用户上传的文件同本软件工作目录中的文件进行比较,看是否有更新的文件和新加入的文件。如果有则通知“前台服务”,由“前台服务”通知各客户端更新文件并且如果当前有正在更新的任务,则停止;如果没有文件更新,则删除上传目录中的文件。
(3)将所有操作通知“过程记录”,由“过程记录”形成日志文件。
1.2.3 版本控制客户端软件
版本控制客户端软件主要是完成本地文件管理和日志功能。
(1)本地文件管理:将接收到由服务器发送的更新文件列表中的文件信息与本地对应的文件进行比较,如果结果不一致则向服务器发送更新文件请求,准备更新文件。每次更新文件前,保存上一次更新的文件。当更新版本出现问题的时候,方便用户进行回滚操作[2,3]。
(2)日志功能:记录每次更新的过程[4],并保存每次更新的时间,文件名称、文件大小、文件校验值、文件位置等信息。
1.2.4 远程安装软件
该软件只有服务器端,客户端不需要安装代理程序。远程安装软件完成两个功能:客户端管理、软件安装。
(1)客户端管理:自动完成本地局域网计算机的搜索或由用户指定扫描某网段计算机,将搜索到的计算机列表保存下来;由于远程安装需要远程计算机的超级用户密码,所以对于用户指定安装的计算机保存其密码,对远程计算机进行管理[5];保存客户端安装软件的历史记录。
(2)软件安装:用户通过选择要安装的软件包,和指定要安装的一台或多台计算机,开始安装程序。对完成安装任务的计算机,交客户端管理部分记录其状态。
2 技术验证
首先用版本控制服务器端软件安装客户端软件,如图4所示(该图为客户端管理界面,显示搜索到的计算机列表),安装完成会有客户端安装成功提示,如图5所示(在安装的客户端机器上看到的客户端软件启动信息),客户端软件已启动运行。
向客户端配置项目管理,即确定需要监视管理的目录以及其中的具体文件,如图6所示。
版本改变提示,当被监视的目录中有文件修改或删除时会给出提示。将IP地址为“7.96.32.24”的客户端即“kjb-zz”的test目录中的gw.cpp文件修改,出现如图7所示界面(客户端监视目录有变化提示)。
3 结束语
文章分析了当前指挥信息系统的特点,研究了相适应的软件版本控制管理软件,针对当前指挥终端进行软件部署的方式进行了改进,能够显著提高软件部署效率及准确性。目前我们对指挥信息应用软件版本控制管理技术的研究已经进入初步使用阶段,还未正式投入使用。应用软件版本控制管理技术在实际系统使用过程中需要系统用户的密切配合。
参考文献
[1]于晓明,网络控制系统控制策略研究[D].杭州:浙江大学,2013.
[2]徐文聪,徐慧,羊帅.基于消息中间件的远程医疗监护技术[J].指挥信息系统与技术,2014(01):52-57,62.
[3]Jon L,Matthew M.Git版本控制管理[M].北京:人民邮电出版社,2015.
[4]斯威司古德.版本控制之道[M].北京:电子工业出版社,2010.
[5]孙子龙.计算机通信与网络远程控制技术应用探析[J].中国管理信息化,2015(08):57.
软件版本控制 篇2
1 SVN简介
SVN (Subve rs ion) 是一种版本管理系统, 其前身是CVS (Concurre nt Ve rs ions Sys te m) , 它是根据CVS的功能为基础来设计的, 它除包括了CVS的大多数特点外, 还有一些新的功能:文件目录可以方便的改名、基于数据库的版本库、操作速度提升、权限管理更完善等。
SVN通过对不同项目建立各自独立的版本库进行管理, 每个版本库很像一个基于数据库的文件服务器, 可以记录每一次文件和目录的修改内容, 这使得用户可以取得文件以前的版本, 检查所做的任何更改。SVN采用HTTP方式访问版本库, 从而使用户可以在不同的电脑上获得 (Check Out) 项目文件, 经修改后再提交 (Import) 到SVN服务器。另外, SVN允许多个用户对同一份文件进行修改, 当提交 (Import) 到SVN服务器时会自动对该文件的不同用户版本进行融合 (Merge) 。当融合过程中有冲突 (Conflict) 发生时, SVN会给出提示信息, 用户可以借助SVN的文档比较功能来解决冲突。
借助SVN的版本管理, 所有开发人员的项目文件都可被同步更新, 因而开发工作可能变得非常顺利。文章所介绍的SVN版本管理系统主要用到Visual SVNServer和Tortoise SVN这两个软件, Visual SVN Se rve r是一款图形化的SVN服务器软件, 提供Subve rs ion、Apache服务器 (提供HTTP服务) 和用户及权限管理等功能;Tortoise SVN作为一款SVN客户端软件, 通过将功能项目嵌入到资源管理器的右键菜单, 并借助其强大的图形化操作方式为用户提供方便快捷的SVN服务。读者可以在www.visualsvn.com和http://tortoisesvn.net/免费下载到这两个软件的最新版本。
2 SVN系统配置和使用
2.1 服务器端
在服务器安装端Visual SVN Server的过程中, 需要填写一个HTTP服务端口号, 如要采用安全连接, 可勾选“Us e s e cure conne ction (https://) ”选项, 其他部分采用默认设置即可。
Vis ual SVN Se rve r中主要包括版本库 (Re pos itorie s) 、用户 (Users) 和组 (Groups) 三部分, 通过各自上下文菜单可以新建版本库、用户和组。通过版本库的上下文菜单“Properties”可以设置其访问用户和权限, 同时其HTTP访问地址也可通过右键菜单“Copy Urlto Clipboard”拷贝至剪贴板, 例如:http://192.168.0.55:8888/s vn/ajs ys/。至此, 一个新版本库建立完成, 非常高效、便捷!
2.2 客户端
安装过程无需太多配置, 安装完成并需要重新启动后, 资源管理器的右键菜单会增加多个Tortoise SVN项目。
接下来向SVN服务器中导入项目, 项目结构可以按照“项目源码”、“项目文档”等进行分类以方便管理。在项目文件夹上点击右键并选择“Import”菜单, 在弹出的对话框中的“URLofrepository”中填入刚才拷贝的URL地址并点击OK, 在填入用户名和密码后, 即可开始将项目导入SVN服务器。
在导入完成后, 还需要对刚才导入的项目通过右键上下文菜单“SVNCheckout”检出, 以后在该文件夹中对文件所进行的新增、修改、删除等操作都将被SVN记录。
被纳入SVN管理的文件夹和文件图标会根据不同状态发生改变, 常见的有:“绿色√”表示没有被本地修改过;“红色!”表示被本地修改过;“黄色!”表示和服务器上版本存在冲突且无法自动融合;“蓝色?”表示该文件或文件夹为新增, 不受版本控制, 可以在提交对话框中选择是否提交到SVN服务器。
在检出后的项目文件夹上点击右键, 我们会发现新增了许多Tortois e SVN菜单项, 下面对常用的几个菜单进行介绍:
SVNUpdate-更新, 使本地项目文件与SVN服务器进行同步。
SVNCom m it-提交, 提交本地修改后的项目文件至SVN服务器, 以便其他项目成员进行同步更新。
Re ve rt-还原, 可以将指定文件或文件夹还原至服务器最新版本。
Show Diff-显示不同, 该功能十分有用, 主要用于本地版本与服务器版本存在冲突时进行对比。
通过以上的简单操作, 我们已经构建起一套完整的SVN版本控制系统, 完全可以胜任中小规模软件开发的版本控制管理。SVN服务器中存储着各个项目的版本库数据, 因此也要做好这些数据的日常备份。
3 SVN服务器备份
Vis ual SVN Se rve r在数据备份方面提供了一条s vnadm in命令, 借助批处理程序并结合Windows系统的“任务计划”功能对版本库数据进行备份。
本例中, 在SVN服务器分区E下建立文件夹svnrootbak, 并将上述三个文件拷贝至该文件夹下, 通过Windows的任务计划功能设定在每天特定时间执行backup.bat, 即可实现无人职守的版本库备份。
在中小规模软件项目的开发过程中, 为了进行有效的协同开发而进行版本控制是一个基本要求。近两年, 基于开源的SVN构建的版本控制系统逐渐成为对软件项目开发进行版本控制的首选。但版本控制不只局限于软件开发领域, 在档案管理、信息管理等领域也可得到应用。
摘要：在中小规模软件项目的开发过程中, 通常由多人分工、共同完成, 这就涉及到大量的源代码和文档。即使在沟通充分情况下, 多人维护同一份源代码也会出现混乱情况, 如何对这些源代码和文档进行有效版本管理, 并进行最终整合, 是软件项目能否成功的关键之一。
版本控制在开发项目中的应用 篇3
软件项目通常由研发小组来共同分析、设计、编码和维护,并有测试小组对完成编码调试的软件进行全面测试。在软件开发过程中,所有的交流反馈都可能导致对软件的修改,小的可能是对源文件中某个变量定义的修改,大的到重新设计程序模块甚至是整个需求分析变动,具体地说在开发模式中会遇到一些棘手的问题,例如:需要将整个软件版本恢复到以前某时间点的状态;控制程序在同一时间只能一位开发人员修改;如何对开发人员编写程序质量进行评估;如何对研发项目进行整体管理;如何用一种有效的机制对项目开发小组成员进行协调;如何对小组成员各自承担的子项目进行统一管理;如何对研发小组各成员所作的修改进行统一汇总;如何保留修改的轨迹以便撤销错误的改动;如何对研发过程中形成的软件版本进行标识、管理等;怎样有效地解决这些问题,管理好项目的每一步运作成为每位项目主管亟待解决的课题。因此必须要引进一个版本管理机制。
2 版本控制
(1)团队合作——默认情况下,某个文件在某段时间只允许一位用户进行修改。但管理员可修改默认设置,允许对一个文件进行多重签出,并保证所有变更都被准确记录。
(2)版本跟踪——对源代码和其他文件的旧版本进行归档和跟踪。
(3)跨平台开发——跟踪跨多开发平台的核心代码中的问题。
3 引入版本控制软件
通过实践,发现在开发过程中采用版本控制软件能较好解决上述问题。
3.1 随时将程序回复到以前某一时间点
版本控制软件可以将某一程序恢复到以前的某一时间的状态,甚至将整个软件版本恢复到以前的某一时间的状态。
3.2 实现程序的互斥性修改
版本控制软件能够实现某一程序在同一时间只能一个开发人员修改。其具体实现方式是:从源文件存放处提出(Chink-out)一个程序,只有当第一个开发人员修改测试完成后,将更新版本的代码做放入(Chink-in)操作,其他开发人员才能Chink-out同一个程序。
3.3 对程序修改进行有效的管理
修改程序的流程为:(1)用户提交需求书,程序员提交程序设计说明书,项目主管审核通过后,管理员将程序解冻;(2)由程序员Chink-out程序;(3)程序员修改程序;(4)修改完成后程序员提交测试请求给测试小组,测试小组进行测试,如果测试不通过,转向第(3)步;(5)测试通过以后程序员填写本次修改解释,然后Chink-in程序;(6)管理员将程序冻结。至此完成一次程序的修改。
3.4 有效的隔离
项目进行到一定阶段,可随时用版本控制软件生成一个新的版本,投入运行;生成运行版本时可以选择丢弃以前所有的修改记录。
3.5 控制软件开发的进度
版本控制软件完整地保存开发中对应用程序每个源文件所有的修改记录,这些记录能使项目主管对整个项目的进度、程序的编写修改情况有一个整体的了解。
3.6 管理文档
在版本控制软件中建立专门的文件夹,用来存放软件开发过程中生成的各种文档。
4 具体实施
目前常用的版本控制软件主要有:Sybase ObjectCycle、Microsoft Visual Source Safe、CVS、SourceGear Vault、VSSRemoting、SourceGear Offsite。
4.1 建立用户
首先建用户,并将用户分为管理员和程序员。其中管理员可对其他用户进行管理,可以冻结和解冻程序。
4.2 建立开发环境
首先建局域网,将其中某台电脑作为版本控制服务器,安装版本控制软件服务器部分的程序和所有源程序,并将存放源程序的目录共享。安装好程序后,每位开发人员配置好开发环境,再运行开发工具,将服务器上共享目录中的项目文件添加到解决方案的“现有项目”中。建立新项目,并将新项目路径放在“解决方案”的“调试源文件”的最前面。
4.3 将程序登记入库
每位开发人员运行开发工具选择版本控制软件;用管理员提供的用户名和口令连接Server;定义用户可用的文件夹;将自己编写的程序登记到版本控制软件中。所有程序登记完成后由管理员将所有程序冻结。
4.4 修改程序
若要修改程序必须由用户提交需求书,程序员提交程序设计说明书,管理员才将程序解冻。程序员将程序Chink-out到自己的工作库,修改程序,测试正确后,提交测试请求。测试人员进行测试,若测试不符合要求,提交程序员继续修改;如果测试成功,程序员填写修改解释,然后Chink-in程序,管理员将程序重新冻结,完成程序的修改。
4.5 新版本的生成
项目进行到一定阶段,可以再建立一个新的版本,新版本的目录名、程序名都可以选择新的名字,可以保留或放弃以前的修改记录。
5 程序集的版本控制
5.1 基于程序集版本控制方法
在类中添加静态只读的字符串类型的属性CodeVersion表示程序集(即变量所在类)的版本号。例如在****年**月**日第一次编写了Member类,该程序集编译后的版本号应为1.0.****-**-**.0,则代码如下:
5.2 对程序集使用强名称
首先,使用强名称工具(Sn.exe)生成密钥文件;再在程序集的属性中加入相关信息,并写入版本号、区域等相关信息,例如:
[assembly:AssemblyVersion("1.0.2005-01-20.0")]//程//序集的版本号[assembly:AssemblyKeyFile("KeyFile.snk")]
6 结语
在一个项目小组开发环境中,版本控制软件的采用是非常必要的,它就好像建立了一部软件开发的编年史,不仅对软件的版本进行控制,还能够协调多个开发人员的工作,对整个软件的开发过程进行有效的管理,大大提高了软件开发的效率。
参考文献
[1]MSDN.
[2].Net Framework SDK文档.
[3]Karli Watson Christian Nagel.C#入门经典.3版.清华大学出版社,2006.
[4]李敏波.C#高级编程.4版.清华大学出版社,2006.
基于数据集成的多版本控制算法 篇4
1.1 数据集成概念
数据集成就是指将分布的、异构的独立信息源中的有用数据抽取出来,经过转换、传输并集成到目的数据库系统中,最终给用户提供一个统一的数据视图。
视图是定义在一个或几个基本关系上的导出关系,当视图中的元组被实际存储时,则称为实化视图[1]。实化视图的优点在于:对实化视图的查询可在预先存储的元组集合上进行,而对传统视图的查询则必须转换成对基本关系的查询。而且当基本关系发生变化时,就必须修改实化视图以反映这一变化。当数据源的数据发生变化后,实化视图即需做出相应的变换以保持数据与数据源的一致性,这一过程就称为实化视图的维护[2]。
1.2 数据的一致性程度
在数据仓库维护环境中,维护算法的选择除了要考察算法效率外,更重要的则需衡定其算法是否能够满足实际数据的一致性。文献[3-6]中提出了数据仓库环境下数据一致性程度的几个层次,在此,按一致性程度由低到高归纳如下:
(1)不一致(inconsistency):当所有数据源基表更新操作停止,视图维护操作完成以后,视图状态与数据源状态不一致(不正确性)。
(2)收敛一致性(convergence):当所有数据源基表更新操作停止,视图维护操作完成以后,视图状态与数据源状态保持一致。
(3)弱一致性(weak consistency):在视图维护过程中,视图出现的每一个状态都能反映数据源更新过程中相应的某一个有效状态。
(4)强一致性(strong consistency):在视图维护过程中,视图出现的每一个状态都能反映数据源更新过程中的某一时刻的有效状态。并且维护过程中视图状态之间的时序关系与其反映的数据源状态之间的时序关系一致。
(5)完全一致性(completeness):在强相容的前提下,数据源更新过程中的每一个有效状态都能找到与其对应的视图状态。也就是说数据源和视图之间的状态变化是一一对应的[3,4,5,6]。
2 视图维护算法分类
视图维护的算法可以分为:重新计算视图方法(recompute the view)、补偿查询方法(compensating queries)、自维护方法(self-maintanence)以及多版本控制方法(multiversion control)。
上述方法中,多版本控制方法已经成为当前的研究热点与焦点。在现有数据仓库产品中,由于对数据仓库的维护是定时进行的,所以数据的维护与读取在某种程度上是互不相关的,但在联机维护环境下,二者之间的冲突却是无可避免的。为了提高查询效率,系统可能就要保留部分汇总视图,如何存取这种视图数据并确保其一致性就成为实体化视图维护的一个关键问题。多版本控制技术即利用版本控制的办法,对不同的数据标以不同的版本戳,在逻辑上即将要维护的与要查询的数据彼此分开,避免了死锁等待的发生,保证了数据的一致性。多版本控制技术为解决实体化视图的联机维护和一致性问题提供了一条新途径[7]。文中对多版本控制技术进行了深入的探讨,具体阐析如下。
3 多版本控制算法
3.1 多版本控制算法下的事务和会话
不需考虑数据库版本信息,维护事务的情况如图1所示。由图1可以注意到维护事务执行的同时,用户事务也在执行,这就意味着维护事务可执行得更久一些或者更频繁一些,同时使得用户事务在数据仓库修改期间也能够执行。
有关会话的策略亦需参照图1所示。由图1可得用户必须能够检测到其会话周期是否已经结束,可以用几种方法来实现。当用户准备去访问一个在用户会话开始之后已被多个维护事务修改过的元组的时候,用户能够检测其会话周期是否已经终止。在这种情况下,正确的元组版本是得不到访问的,因为当前的版本和更新以前的版本都被最近的更新所维护。
3.2 修改关系表
数据仓库中的每一个关系表都需要用额外的属性去扩充。例如,设A={A1,A2,…,An}是关系R的初始化属性集合,A′={A1,A2,…,Ak}是A的属性子集,这些属性都是可更新的。R的扩展表为{tupleVN,operation,A1,A2,…,An,A1p,A2p,…,AkP},其中,Aip表示更新前的属性,与可更新的属性Ai相对应。属性tupleVN包括维护事务的版本号maintenanceVN,该事务对应最近的元组修改;属性operation包括了作用在这个维护事务上的逻辑操作;属性{A1,A2,…,An}包括着元组属性的当前值,更新前的属性{A1p,A2p,…,AkP}则包括被维护事务更新前的可变化的属性值(在执行插入操作的情况下,更新前的属性为空,在删除操作的情况下,则包括了删除前的值)。
在最坏的情况下,即每一个属性都是可更新的时候,则表示每一个元组的多个版本均需要数据仓库的多倍存储空间。但是最经常的,数据仓库中有很多属性并不能更新。例如,数据仓库总会包含多个汇总表,这些汇总表通常会被认为是select-from-where-groupby的聚集视图。虽然维护事务能在一个汇总表中对元组进行插入删除操作,但是那些group-by属性的值是不能修改的,只有那些表示聚集函数结果的属性才是可更新的。因此,对汇总表而言,本算法所要求的额外存储空间是很小的。
3.3 对用户的算法
现在将用提取一个元组的正确版本以便用户能访问到数据库的某个一致性状态来说明对用户的算法。常见的方法是通过查看tupleVN,使用户得以确认应该访问元组的当前版本,还是访问元组更新前的版本。并且,通过查看operation属性,当前属性,以及更新前的属性,将能得到任一元组的恰当状态。
用户所访问元组的版本就是在数据库版本sessionVN之中的当前版本,同时这也意味着该版本包括了所有满足maintenanceVN<=sessionVN的维护事务的作用影响,而没有包含其他维护事务的作用影响。
前已叙及,tupleVN包括着最后一次修改元组的维护事务的maintenanceVN,在此有3种情况要考虑:
(1)sessionVN>=tupleVN:访问元组的当前版本。
(2)sessionVN=tupleVN-1:访问元组更新前的版本。
(3)sessionVN
第一种情况表明,元组当前版本的状态为:该版本与当前数据库版本tupleVN是一致的,也就是相同的。第二种情况说明,更新前的元组版本的状态为:此版本就是当前数据库版本,也就是tupleVN-1。第三种情况,也就是会话到期的这种情况就表示了既然只有元组的2个状态版本可以访问,那么此时已经无法确定数据库版本中的元组状态是tupleVN-2还是更早的。因此在这种情况下,应该通知用户开始一个新的会话。
根据operation属性,应如何提取元组当前和更新前的版本,则如表1所示。比如,在元组更新前的版本被访问并且operation=“insert”的状况下,元组就应该被忽略。
3.4 对维护事务的算法
当一个维护事务访问一个元组的时候,总是访问当前的版本。因此,必将遵循表1的第一行去访问元组。
当一个维护事务对一个元组进行插入,删除,或者更新操作的时候,多个动作将会发生,以便维护元组当前的版本和更新前的版本。所发生的动作列置如下:
(1)在一些情况下,当前的属性值被移植为更新前的属性值,以便元组更新前的版本得到保存。
(2)当前的属性值设置为维护事务操作后定义的值。
(3)tupleVN设置为maintenanceVN。
(4)operation设置为逻辑操作(insert,delete,或者update)。
这些操作被维护事务作用在元组上。由维护事务作用的逻辑操作结果与作用在元组上的物理操作结果可能会有所不同。例如,当一个逻辑操作是删除操作的时候,元组通常并没有在物理上被从数据库中删除,这是因为元组更新前的版本可能还需要被用户所访问。一旦逻辑上已经删除的元组不再为用户所需要,那么这些元组就将被进行垃圾回收,该回收机制即是通过周期的运行以在物理上将其删除。此后,将在下一步的工作中去检验这个垃圾回收机制。
另外,在属性operation中的操作记录都要表现出由维护事务作用在元组上的所有操作的网络效应。举例说明,如果一个维护事务插入了一个元组,然后在该维护事务中更新了这个元组,那么网络效应就仍然表现为一个插入操作。如果operation错误地进行了更新操作,那么当用户查看元组更新前的版本时,用户访问到的将是更新前的属性值,而不是忽略这个元组。
(5)在元组上执行恰当的物理操作。
作用在元组上的准确操作依赖于3个条件:维护事务的操作,元组的tupleVN属性值和元组的operation属性值。假如要进行以下操作:插入,更新和删除。则将maintenanceVN值赋给维护事务,再将元组已经存在的值指给tupleVN和operation,这样就表明了作用在元组上的正确的物理操作,以便当前和更新前的元组版本进行保存。设:
(1)CV表示元组的当前属性值。
(2)PV表示元组更新前的属性值。
(3)MV表示在维护事务操作中说明的属性值(如果这个维护事务操作是一个插入或者是一个更新操作)。
因此,表达式“PV<-CV”说明将元组更新前的属性值设置为相应的当前属性值,“CV<-MV”则表示将元组当前的属性值设置为维护操作中作用的属性值。
注意到,既然在一个时刻只能有一个维护事务在执行,那么就可知道tupleVN<=maintenanceVN。每个表的第一行指明了当元组版本号小于维护事务版本号的时候,将发生的动作,即要进行的操作。当tupleVN=maintenanceVN的时候,元组被同一个维护事务预先修改了。此种情况下发生的动作将在每个表的第二行作以说明。正如前面所提到的,赋值在第二行的operation值说明了由作用在这个元组上的维护事务所采取的全部操作将产生的影响。
4 结束语
本文主要介绍了一种数据仓库中基于数据集成的多版本控制算法。重点介绍了数据仓库中基于数据集成的多版本控制算法中事务和会话如何进行、关系表如何修改、对用户算法描述以及对事务维护算法的描述。今后还要进一步改善多版本控制算法,使得在并行的同时进一步提高效率。
参考文献
[1]HAMMER J,GARCIA-MOLINA H,WIDOM J,et al.The St-anford data warehousing project[C]//IEEE Data EngineeringBulletin,1995,18(2):41-48.
[2]WIDOM J.Research problems in data warehousing[C]//Proce-edings of the 4th,Int’L Conference on Information and Knowl-edge Management(CIKM),1995,19(1):124-129.
[3]ZHUGE Y,GARCIA-MOLINA H,HAMMER J,et al.View m-aintenance in a warehousing environment,In SIGMOD,1995,32(1):256-262.
[4]ZHUGE Y,GARCIA-MOLINA H,WIENER J L.The strobealgorithms for multi-source warehouse consistency.PDIS'2005,Miami Beach,Florida,1996-12.
[5]ZHUGE Y,GARCIA-MOLINA H,WIENER J L.Consistencyalgorithms for multi-source warehouse view maintenance.Dist-ributed and Parallel Databases Journal(DAPD),Kluwer,1997-07.
[6]ZHUGE Y,WIENER J L,GARCIA-MOLINA H.Multiple vi-ew consistency for data warehousing.ICDE'97,Birmingham,UK,1997-04.
软件版本控制 篇5
关键词：Git版本控制,物联网,项目式教学
1 物联网实践类课程的传统教学方式
物联网工程专业自2011年起进军各高等院校、职业学校, 已经培养出了若干批毕业生。在职业学校的人才培养方案中, 新兴的物联网工程专业相比传统专业更注重学生的创新、实践与协作能力的培养, 物联网工程专业的性质也决定了实践教学成为该专业教学体系中不可或缺的重要环节[1]。
目前物联网实践类课程采取的教学方式与其他专业课无异, 根据实验设备模块设计不同的项目任务, 学生在完成项目的过程中逐渐掌握相关知识, 但是也存在了以下问题[2]:
1.1 任务分配
为了培养学生的独立操作能力, 同时为减少偷懒、抄袭现象, 最好是一人一题, 但是这种方式不利于提高学生的团队协作意识, 并且在物联网技术中, 工程项目的工作量很大, 学生不可能在短短几周内单独完成所有功能, 即使完成了, 质量也不会太高;若将任务交给一组学生完成, 又很可能出现“一边倒”的现象, 即只由该组的某一名或几名同学全部包揽, 其余同学共享这些同学的劳动成果, 使得教师无法真实评价学生的能力, 对于学生来说也不能得到充分的锻炼。
1.2 过程管理
物联网实践类课程大部分功能都是通过代码体现, 但是教师评价不能仅仅针对结果, 因此教师需要对编码质量进行批改, 而由于项目工作量大, 学生一般都将精力放在功能上却忽略了代码质量本身, 这给教师带来的最大问题就是批改代码工作量太大。另外由于学生较多, 教师无法做到一对一的教学管理和跟踪, 只能根据考勤和学生提问来进行评估, 由于过程化考核监督的漏洞, 可能会出现部分学生借鉴网络现成代码来完成项目, 带来一些后续问题。
1.3 任务传承
由于工程量大, 代码的阶段性保存度较差, 学生的项目代码仅仅作为作业上交, 完成得较好的作业无法作为案例分享给他人, 并且已完成的作业也无法进行二次开发造成一些资源的浪费[3,4]。
针对这些问题, 本文提出将基于版本控制技术[5]的代码管理平台Github应用于物联网技术的实践课程教学环节中, 提高实践教学水平和人才培养质量, 增强学生实践能力和创新精神, 提高学生就业竞争力。
2 版本控制技术的内涵
Git分布式版本控制系统, 主要应用在软件项目托管平台, 可通过网页访问公开或者私人项目, 浏览源代码、修改代码及注释。其最突出的特点在于“阶段版本控制”, 它可以浏览任意提交过的版本并提供文件历史库, 团队成员也可以在其内置聊天程序中进行交流, 非常便捷。Github就是提供基于Git的版本托管服务, 2008年上线, 发展非常迅速, 目前已经成为全球最大的开源社区。本文利用Github网络资源, 将阶段版本控制的理念投放到教学中, 帮助教师完成项目式实践教学, 也就是对每个学生的每个“阶段”学习成果 (“版本”) 进行“控制”。
(1) Github网站具备代码审查、问题追踪等功能, 可以容纳数万名用户群, 又是一个完全免费、开源的系统, 在业界具有很多成功案例, 满足课程实现条件。
(2) 在使用Github网站时需要每名学生熟练掌握版本上传、管理等操作, 可以杜绝传统教学方式中可能出现的学生偷懒、抄袭等现象, 并且由于项目的实施大多以团队小组为单位, 学生在完成任务时不受场地限制, 任何时间不仅可以向教师求教, 也可通过网站自带的聊天程序广泛进行交流沟通, 在高效学习专业技能的同时也提高了学生的沟通表达能力。
(3) 新技术的实施对于教师而言也是一项挑战, 目前很多高职院校的专业课教师都是从学校毕业后直接为师, 理论基础比较扎实, 工程项目经验方面相对欠缺。Github是一个成熟的项目开发、管理网站, 作为双师型教师需要熟悉企业项目开发的工作流程和管理模式, 这样才能培养出适合于企业要求的毕业生。
3 版本控制技术在教学中的具体运用
由于Github是开源的版本控制, 在物联网技术课程的具体任务实施环节, 教师和学生可以不受实验室地点约束, 将教与学延伸到课外, 及时对学习成果进行检阅, 得到科学合理的评价。
为具体说明版本控制技术在教学中的应用, 以综合项目智能超市管理系统设计为例, 该设计在基本的用户账户模块、数据适配模块基础上增加了环境检测模块、安防监控模块、商品管理模块和物流追踪模块, 在教学中属于高阶练习, 一般安排在课程接近尾声阶段, 是大型综合课程设计。教师在设计时分为三个级别, 如图1所示:
级别1的四个小组将分别建立一个activity, 显示、访问并处理用户账户数据库对应信息, 所需牵涉技能与难度大体相当, 包括界面布局, 控件管理, 数据处理, 函数管理与使用, 基础数据库更删改查操作;级别2的四个小组将分别建立一个滑屏界面的frag门徒, 显示、访问并处理数据库数据或根据API接口访问操作外部设备外面, 相比级别1, 级别2需要了解fragment加载, 更理解View的自定义, 更复杂的数据操作, 优化数据库访问, 外部函数访问, 因为访问外部设备数据, 所以需要考虑线程优化;级别3的三个小组将不再分别编写程序界面, 重点在编写后台数据库与广播处理程序, 需要极高的线程管理能力与数据分析能力, 训练学生对物联网传感器系统运行的了解与数据库数据结构的掌握。三个级别难度循序渐进, 适合不同能力层次的学生, 便于教师因材施教, 同时由于Github的开源特性, 任何适合任何阶段都可以新增成员, 便于低级别任务的学生完成任务后参与到高级任务中, 逐步培养能力, 提高他们的团队意识。
在授课前, 教师需要提前安排任务分组, 由学生自由分组, 每组3-4人, 选择任务模块, 创建版本库, 将远程代码克隆到本地, 然后在自己的机器上完成功能的编写, 团队成员在遇到问题时可以利用网址自带的聊天程序进行交流, 方便快捷, 每天定时上传已测试代码。教师可以将代码记录情况作为过程化考核的依据, 并且及时跟踪学生进度, 帮助学生找到原因, 最大限度地避免学生懈怠及抄袭。在审核代码时, 教师可以利用系统对某些不符合规范要求的代码拒收, 也可以利用其质量分析功能, 对已交代码进行评审, 提高了评价效率。当整个项目完成后, 也可以根据网站的统计功能, 对团队和成员的贡献率进行客观公正的打分, 并且将完成出色的代码保存下来作为后续的教学补充资料。
4 问题与思考
目前对于版本控制技术在物联网实践类教学中的应用还处于探索阶段, 也存在很多问题, 由于Github本身是为广大编程爱好者提供交流的平台和外包服务, 并不是专业的教学平台, 在使用中需要适当取舍, 经过分析、整理出以下问题需要改善:
(1) 考虑到学生实际情况, 对完成相同任务的学生代码进行重复性分析, 根据其相似度分析是否存在抄袭, 最大范围内减少学生雷同作业, 督促学生积极思考练习。
(2) 过程化考核时针对版本进行数据分析, 教师可以全面了解学生的设计思路及修正过程, 针对教学资源和代码活动数据, 为今后的教学改进提供依据, 改善教学方式, 提高教学效果。
5 结论
本文尝试将版本控制理念注入实践教学, 并在物联网技术实践类课程中进行实验探究, 便于教师进行过程考核和提高教学效果, 能够提高实践教学水平和人才培养质量, 增强学生实践能力和创新精神, 以及提高实训基地建设与管理水平。
参考文献
[1]王敏, 张捐净.物联网导论课程实践教学探索[J].安阳工学院学报, 2014 (06) :93-95.
[2]綦志勇, 常排排.高职高专嵌入式与物联网专业传感器应用技术课程实验电路设计与实现[J].电脑知识与技术, 2016, 12 (10) .
[3]何凤梅.技师学院物联网导论课程的实践教学探索——以温州技师学院物联网技术应用专业教学实践为例[J].中国培训, 2015, (10) .
[4]曹建峰.物联网导论课程的构建与实施[J].物联网技术, 2014 (05) :86-87.