版本控制、Git和Domino

版本控制

一提到版本控制,程序员们就会想到他们工作中用到的各种源代码控制工具,Subversion、Git、Mercurial……实际上源代码之外的许多其他文件也会有版本控制的需要。而版本的想法和对其的管理更是在计算机出现之前的印刷以至手写时代就一直存在。版本是作品生长衍变的徵象。手写和印刷时代的文字作品之还仅是记录它的修改生长。及至计算机和电子文件出现,文件大小、内容复杂程度、版本更新速度都空前增加。除了单纯记录不同版本,版本控制又被提出许多新的功能需求:恢复到任一历史版本、比较两个版本之间的差异、创建多个分支版本、合并不同版本。尤其是对程序员而言,这些功能对于调试错误、了解代码演变、多人合作以及为多个用户和目的开发等任务都大有裨益。

Git

与其他软件工具一样,版本控制系统(VCS即Version Control System,或RCS即Revision Control System)也伴随着实际需要不断演化生长。起初所有被管理文件的数据都保存在本机的存储库(repository)里,后来进化成客户端服务器模式,存储库保存在服务器上,版本控制系统从而由单机版变成了可多人合作的网络版。这样的架构唯一的缺点是只有服务器上保有文件的完整历史数据,每个客户端仅有当前工作的版本。这样在多个版本之间的切换、比较、合并等操作都需要连接服务器查询和传输数据。此外一旦服务器上的存储库被损坏,所有的历史积累将无法挽回。为了更加适应多人自由开发的环境,分布式版本控制系统(DVCS即Distributed Version Control System)诞生了。就像分布式数据库系统在不同节点上有单个数据库的多个副本一样,每个DVCS用户机器上都保存了完整的存储库。在无联网的单机状态下,程序员也能使用版本控制的所有功能,联网时则可以同服务器上的存储库同步。

Git就是一款优秀的分布式版本控制工具。它最初是为了Linux的程序员开发系统而编写的,现在已经成为,特别是开源领域,最流行的版本控制工具。GitHub即依讬此系统成为最大的源代码托管网站。与前驱相比,Git有一些特别的理念,例如每个版本保存的不是文件的差异,而是完整的文件(如果某个文件没有改变,则包含对上个版本文件的引用)。网上有很多优秀的介绍和教材,例如Git官方网站上的文档http://www.git-scm.com/doc还有这篇通俗易懂、图文并茂的git concepts simplified

Domino

在Notes杂谈系列文章里,我反复提到和讨论了Domino作为专有的(proprietary)开发平台的独特性,就像与世隔绝的科莫多岛上孕育出奇异的科莫多龙一样。在版本控制领域,Domino也有独特的“国情”。

困难

表单视图等设计元素都是以二进制格式保存在数据库里。与文本格式的文件相比,二进制文件在比较版本差别和合并方面都有困难。DXL的发明使得在设计元素和XML文件之间相互转换成为可能。但是长时间来DXL有很多bug没解决,不能保证相互转换的精度。直到R9面世,IBM才对DXL有了信心,在Designer里加入基于它的版本控制特性。

在主流的采用某种编程语言开发的环境里,文件都是文本格式,版本控制系统只需处理文件和文件夹。Domino平台下要达到版本控制系统的这个初始环境就大费周章。Designer先将数据库里的设计元素映射到一个虚拟的文件系统(virtual file system)里,例如一个表单Person就会被映射到数据库路径下的文件Forms\Person.form。Desinger迁移到Eclipse平台上后,一个Domino应用程序作为一个Java项目来校验、编译,利用Eclipse的种种视图和编辑器来显示和修改设计元素,Eclipse读写的就是这个虚拟的文件系统。在设计元素到文件的转换过程中,表单、大纲这些以用户界面为主的元素都经过DXL转换成XML文件;脚本库(Java脚本库是个例外)、Java设计元素、XPages这类基本为了容纳代码的设计元素被解析成两个甚至更多文件,一类是容纳代码和配置本身的文本文件,另一个是记录设计元素元数据的metadata文件。例如一个名为task的XPage会被转换成task.xsp和task.xsp.metadata,前者的内容就与在XPages编辑器的源代码视图里看到的一模一样。

为了让Designer外部的版本控制工具能够访问到这个虚拟文件系统,R9增加了一组features,能够设定一个本机的文件夹,使其中的内容与虚拟文件系统同步。如此,版本控制系统面对的就是与其他项目无异的文件系统,它对此文件系统的内容做的任何改变,如切换版本、合并又会被Designer检测到并自动转换回设计元素。

经过这种对用户透明的设计元素与文本文件之间的自动双向转换,就能对Notes应用程序运用任何版本控制工具。不过二进制格式带来的问题并没有完全解决。版本控制工具可以比较某个表单两个版本之间的差异,但其结果是Notes程序员不习惯和不易阅读的XML。原因就是Domino并没有被改造成以XML的格式来记录设计元素,DXL只是勉强将它们输出为XML,许多内容仅仅是以<rawitemdata>元件将二进制的内容以字符编码显示。例如表单的布局信息记录在$Body域里,转换成XML后看不到HTML那样的DIV、TABLE,而是一堆字符编码。

<item name=‘$Body‘sign=‘true‘><rawitemdata type=‘1‘>gQKC/1oAAQAAAAAAAAAAAKAFAACgBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAJSHAAAAAAAAAAAAAAAAAQAAAAQAAAC7/zIAAQAYANLVpGPEnCQAAAAWAAEABwBbQWRtaW5dAOcAdQIDAAcADAAFAAkwUzBFAIMEAQCF/xUAAQAACkFkbWluV3JpdGVyczoA3QYAAIr//v9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAB4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACK/1QAjwABBQYgAgAAAAAAAAIBAAAKJAAAAAAAAAAMAAAAAAAkAAAAFgD0AAEABwBbQWRtaW5dAB8CAwAHAAwABQAJMFMwRQBBZG1pbldyaXRlcnPeBgAAiv+F/wgAAQAACoECgwQBAIX/EAABAAAKV3JpdGVyczrdBgAAiv/+/1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AHgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA……</rawitemdata>

这样的XML是有名无实的,与二进制格式差别不大,不是供人阅读的,只有转化回设计元素才能由Notes客户端或服务器解读。版本控制工具比较出的差异若是位于这样的字符编码实体内,程序员根本无法判断其含义。同理,同一设计元素的合并遇到冲突时,程序员也无法直观地了解内容以化解。只有对上举代码类设计元素,比较与合并功能才能发挥威力。

综上可见,Domino应用程序的版本控制,最多只在单人开发时好用,团队开发场景下常见的比较和合并开发人员各自的分支版本都会时时受限。

需求

Domino应用程序的源代码管理从未被很好地解决过,但是Notes程序员似乎不以为意,甚至有很多人从来没意识到Git之类的版本控制系统之需求。原因同样来自Domino平台的特殊性。作为一个快速开发环境,Domino提供了现成的用户管理、权限管理、与邮件的集成以及视图等等基础功能(infrastructure),省去了大量的用户代码。另一方面,数据库与体系的限制使得Domino只适于做某些领域的开发,做出的系统也不会像通用语言如Java的大型项目那样庞大。所以一个Domino应用程序的代码量较少,往往都是一个程序员包办。最后,Domino应用程序的代码高度耦合,XPages引入之前,很多系统的数据设计、用户界面、业务逻辑全都混在一起,即使采用XPages,还是要有良好的设计才不至把视图层和业务层混合。代码模块化程度不高,也给多人同时开发造成障碍。所以即使在高度依赖Domino的大公司,需要团队开发的项目也罕见(当然一个项目团队有多人分别负责需求、测试和开发是很常见的),即使是这样的项目,也是多个数据库分人负责。

总之,一方面Domino应用程序规模小,可视化程度高,多人合作开发的需求不大;另一方面在Domino中应用版本控制系统过去困难重重,现在效果不充分。这并不是说,Domino应用程序就一直没有过版本控制,许多公司也开发了内部使用的系统管理Domino数据库的版本。但这类系统是囫囵吞枣,将整个数据库作为附件或文件保存。既无法高效地切换版本,更不能自动比较差异和合并代码。Domino平台与版本控制系统绝缘了几十年,在可见的将来也会继续独行下去。

Domino+Git

上面分析了,Domino Designer自R9起,对一个应用程序应用外部的版本控制系统成为可能。国外有一些热心人还开发了Designer与Subversion等工具集成的插件。不过我在上面已经泼了冷水,这样的版本控制,单人开发时用来管理历史设计可以,要发挥版本控制的更多功用就会遇到掣肘。这一节就介绍一下Domino+Git的使用方法。

在导航视图内选中要启用版本控制的应用程序,在右键菜单中选择Team Development,子菜单中的第一项Set Up Source Control for this Application,在随后的对话框里选定一个文件夹用来容纳该应用程序被转换输出的文件,如D:\Lotus\Notes\Data\workspace\task。Domino一侧的设置就完成了。该子菜单中的其他几项顾名思义都很好理解。

接下来就可以用Git做上面所说的能做的事。运行Git控制台(Git shell),转入D:\Lotus\Notes\Data\workspace\task(在其中手工创建一个过滤文件.gitignore)。

git init:创建了一个新的存储库。

git add .:将所有文件编入index。

git commit –m initial:第一次提交。你的Domino应用程序已经开始被Git管理了。

git branch:可以看到默认创建的master分支。

在进行版本管理的过程中,有意思的是可以从一组文件的视角来看待Notes应用程序的组成,以及每次修改带来哪些文件的变化。有兴趣的朋友还可以将自己的存储库推送到GitHub上。

时间: 2024-10-13 10:55:19

版本控制、Git和Domino的相关文章

iOS版本控制git小结--yoowei

一:准备工作 1.什么是git? git是一款开源的分布式版本控制工具. 在世界上所有的分布式版本控制工具中,git是最快.最简单.最流行的. 2.git和SVN的简单对比 速度 在很多情况下,git的速度远远比SVN快 结构 SVN是集中式管理,git是分布式管理.分布式和集中式的最大区别在于:在分布式下开发者可以本地提交,每个开发者机器上都有一个服务器的数据库. 其他 SVN使用分支比较笨拙,git可以轻松拥有无限个分支 SVN必须联网才能正常工作,git支持本地版本控制工作 旧版本的SVN

版本控制Git实际开发笔记

这里会把自己实际工作当中用到的git操作记录下来,供自己学习: ①新建分支: 在新版本要开发时,会基于最新版本新建一个分支,创建步骤如下: 新建本地分支[注意:这时只存在于本地,远程仓库还没有生成]: 然后切换到新建的本地分支: [说明]:以上两部操作可以合成一个命令:git checkout -b developer_V1.3.0 最后push到远程: 最后去网页中就能看到远程新建了这个分支了: ②删除远程分支: git branch -r -d origin/branch-namegit p

Help-IntelliJIDEA-2019-基础设置:3. 版本控制Git

ylbtech-Help-IntelliJIDEA-2019-基础设置:3. 版本控制Git 1.返回顶部 1. 3. 版本控制Git具体步骤:顶部工具栏 Configure ->Settings -> Version Control -> Git示例: IDEA默认集成了对Git/Svn的支持 直接设置执行程序,右边Test提示成功即可. 2. 2.返回顶部 3.返回顶部 4.返回顶部 5.返回顶部 6.返回顶部 作者:ylbtech出处:http://ylbtech.cnblogs.

版本控制——Git 使用笔记,以及Windows搭建Git服务器

Git和Github的关系 链接:http://www.zhihu.com/question/21907548/answer/95284202 来源:知乎 Git是一款免费.开源的分布式版本控制系统 Github是用Git做版本控制的代码托管平台 相当于本地.公司服务器.Github网站服务器都装Git做版本控制,只不过Github的服务器强大些,对全球用户托管的项目用Git做版本控制! 正是由于Github用Git做版本控制,所以可以轻松的记录项目的变迁史,然后有了下图 git是一张弓,git

版本控制 - Git

此篇blog只是对http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000 研读后的总结,还请各位看客细细品味原著. 一直以来,只是听说版本控制当推崇类似git这样的分布式版本控制,但之前使用的是SVN/subversion,而且也只限于会用add commit功能.所以连‘知其然’都没有做到.今天将对git理解整理如下,以便后用. 1. 设置机器身份: $ git config --gl

版本控制-git(二)

上次文章给大家介绍了Git的一些基本知识(http://www.cnblogs.com/jerehedu/p/4582398.html),并介绍了使用git init初始化化版本库,使用git add增加文件到版本库,使用git status查看版本库的状态信息,使用git commit最终提交文件到版本库.上文最后在提交时,会出现问题导致提交不成功,这是因为我们没有对git进行配置. Git配置 Git最重要的配置信息就是用户名和电子邮件地址.每次Git提交时都会使用这两条信息,用来标识是谁提

版本控制Git(1)——理解暂存区

一.svn和Git的比较 我们都知道传统的源代码管理都是以服务器为中心的,每个开发者都直接连在中间服务器上, 本地修改,然后commit到svn服务器上.这种做法看似完美,但是有致命的缺陷. 1. 开发者不能本地跟踪代码版本. 所有的信息都是在服务器上.  你把本地的代码改了很多,但是又不能提交.通常,本地只能缓存一个版本.对于小项目无所谓, 但是项目一复杂,人员多就麻烦了. 通常你本地的代码都全是红色的.自己都不知道今天修改了什么, 有哪些修改是真正应该提交给svn的. 2. 因为第一点,一旦

版本控制git(三)-git分支

通过本系列的上两篇文章(查看系列文章:http://www.cnblogs.com/jerehedu/p/4607599.html#bbkz),我们已经知道了如何使用Git完成对文件的版本控制.本次我们继续学习如何通过Git进行分支管理. 首先,我们要弄明白什么是分支.通过git log 命令我们可以查看版本库的提交日志,如图: 那么这些commit之间存在什么关系呢?实际上每次commit的时候,提交对象都会保存一个指向上次一commit版本的指针,经过多次提交之后,git通过这个指针将多个提

代码版本控制Git工具使用详解

一.Git简介 Git是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目. Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件. Git 与常用的版本控制工具 CVS, Subversion 等不同,它采用了分布式版本库的方式,不必服务器端软件支持. 二.Git安装 1.centos7安装Git [[email protected] ~]# yum install -y git 2.查看安装的Git版本 [[email