- 浏览: 1101621 次
- 性别:
- 来自: 成都
文章分类
最新评论
-
Alice南京:
这个是cookies是取的同一个用户的吗?多用户如何模拟?是否 ...
LR使用web_add_cookie函数进行cookie模拟 -
绝杀fc小飞侠:
测试了以下,没有进度条出现,不知道是否这两个文件的原因,jqu ...
上传时显示进度条 -
libixionglbx:
[size=large][/size]12321
ASP.NET 缓存 -
GeneralSnow:
没有有一个共用的模板
自己编写程序批量合并多个“规范定义电子名片(vCard)”文件 -
John_Kong19:
莫非现在文章题目和内容不一样是种流行吗
在SQL Server中,索引是一种增强式的存在,这意味着,即使没有索引,SQL Server仍然可以实现应有的功能。但索引可以在大多数情况下大大提升查询性能,
下面的英文文章是我去年读的,当时看见了DTR的如此功能感到无比兴奋,确实,当年我用ClearCase时,很多问题都在这里得到最好的解答。今天我重读这篇文章,结合最近我安装配置DTR的一些感受,解读一下这篇好文。
SCM(Software Configration Management)是软件开发管理的重要的手段,也有很多工具来支撑,最为著名的就是Rational的ClearCase,其它的还有CVS、Perforce等。软件配置管理的重点就是版本管理,但是不局限,非常重要的还有变更管理。可以说,我们希望软件开发过程有如同汽车生产线式的管理模式,SCM是实现这一目标的基石,有了好的SCM才会有好的软件过程管理,有了好的软件过程管理才能真正实现CMM的目标,才能够更好得保证软件生产质量。
文章以对话的形式来说明DTR相对传统SCM供应商的优势所在。
提问者也是对通常的SCM工具非常了解,她提出疑问,为什么有那么多成熟的SCM工具(Preforce,ClearCase),我们还要采用DTR呢?相对Perforce,Changelist就是DTR的Activity,Branch就是DTR的WorkSpce,有什么区别呢?
作者比较了Perforce和DTR的特点,他认为这不是从表面现象去看要深入本质:
首先,Preforce的系统架构是基于单服务器模式,也就是不支持分布式模式,作者问到提问者,是不是在印度班加罗尔从德国的Preforce服务器上巨慢,提问者表示同意。
其次,DTR是支持DeltaV的协议,这个是WebDAV的一个扩展,WebDAV是基于Web的分布式文档版本管理的协议,也就是说DTR支持分布式模式。Preforce不支持这个协议,因为SAP的DTR的战略目标是要实现可以修整的(open-ended)系统,可以说这一目标是管理软件必须支持的。这也是本人痛苦的体会。
最后,Preforce由于是单服务器模式,那么建立两个独立的服务器不能实现彼此间不同版本的软件的合并,而支持分布式的DTR就没有问题,你可以把你的workspace建在不同的repositories上,系统会帮你实现合并。
提问者又问了,那Preforce不支持,著名的ClearCase可是支持分布式啊,而且已经有很多年了。
作者表示同意,但是觉得只有这个特点还不够,
作为像SAP这样的大型管理软件来说,不可能把软件在用户那里一安装就没事了,客户就会一成不变的使用,而是要考虑变化,包括软件公司自身的修改和用户的修改,这些的版本变化也必须得到控制,这就是DTR能够直接交互到客户那里的特点,可以实现短期交互和客户共同修改的功能,真是很强,其实这些都是来自SAP多年的开发实践。我使用ClearCase时的困惑,这里得到充分解答。
DTR非常强调控制,而且是严密的控制,从开发源到客户。但是也讲究灵活,变更粒度是可以选择的,除了“活动”还有“传播列表”。另外,一般的SCM工具都讲究分支要回归主线,但是DTR可以选择不回归,这些都是DTR的特点。
更多的在原文中,各位读后希望与我共享,谢谢!
Why DTR ? Why not Perforce or ClearCase...?The other day, I struck up an interesting conversation with a colleague who had some strong views about SCM tools, especially concerning SAP's new Design Time Repository ( DTR ).
"I've taken a look at DTR" she said, "and I still cannot figure out why we had to build our own Version Control tool when there are so many mature tools in the market. I mean, take Perforce or ClearCase - they've been around for years and have proven their strength in supporting large scale distributed projects. So why reinvent this technology ?"
"There are a number of sound reasons behind that" I replied.
"I'd really like to hear them out" she said. "To me, DTR looks similar to Perforce - you have the same file/folder checkout-checkin model, 'changelists' in Perforce are called 'activities' in DTR, and Perforce Branches map to DTR workspaces. Old wine in a new bottle, isn't it ?"
"Not really. I'll explain the differences in a moment, but regarding the abstractions like 'activities' and 'workspaces' - these are from the DeltaV standard which DTR implements and not- "
"What's DeltaV ?" she interrupted.
"DeltaV is the versioning extension to the WebDAV standard. WebDAV defines a standard way to access and manage files over the web. DeltaV adds versioning support to this and defines the protocol to perform tasks related to configuration management and version control. Implementing an SCM tool based on this standard - and not on some proprietary technology the way Perforce does - is in line with SAP's strategy of creating 'open-ended' systems."
"That sounds okay, but it doesn't justify the development of a full blown SCM tool to meet this end !"
"True. The reasons for that are different. You work with Perforce from Bangalore, don't you ? How fast is it ?" I asked.
"Irritatingly slow. But that's understandable considering the fact that the Perforce server is in Walldorf and we access it over the WAN." She seemed to have accepted her fate calmly.
"Understandable yes, but acceptable ? I think not. Perforce has only one model for distributed development - a central server ( what they call Depot ) to which clients connect from different places, even across continents. But with DTR, you can also replicate sources between repositories in different locations. So if you were to move your sources to DTR, there will be a DTR Server configured in Bangalore to which you will connect, and the sources you modify will be replicated to the DTR Server in, for example, Walldorf, and also in the reverse direction. "
"How does that work ?" she asked. "I mean, what is it in DTR which allows it to replicate sources in a way Perforce cannot ?"
"Perforce has no concept of propagation of sources in a distributed landscape. You can integrate your changes from one Perforce Branch to another one in the same depot, not across depots. In DTR, the analogous abstraction 'workspace' is not tied to a physical repository - so integration of changes is possible between workspaces in different repositories. If the target workspace is in another repository - in another location - then you only need to export your changes from the source repository, import it into the target repository, and then integrate the changes into the target workspace."
"Much better, I agree. But what about ClearCase - they've been supporting replication for years!" There was a twinkle in her eyes; she probably thought she'd got me here.
"True. ClearCase has what they call a VOB - Versioned Object Base - which is a source tree in the repository. So in a way it is something like a Branch in Perforce or a Workspace in DTR. And a VOB can be distributed over a WAN - this is done by having multiple replicas of a VOB, and allowing users in different locations to work with their replica of the VOB. Then, at regular intervals, you can synchronize sources between these different replicas and thus get the changes made in other locations."
"Just what we need, isn't it ?!" she asked, still excited.
"For distributed development, perhaps yes." I said. "But SAP has other requirements which ClearCase does not fully meet. The most important one is support for delivery of sources to customers. As you know, SAP delivers its application sources to customers, and these sources can be modified by them. So we need an SCM tool which supports the functionality of propagation of sources to customers in such a way that it satisfies some important attributes."
"What attributes ?"
"Firstly the tool must support upgrading software delivered earlier such that customer modifications are not overwritten. This is possible only if the tool is able to automatically detect conflict situations caused by propagation in any direction. In DTR, this is possible since it maintains a global version history - a version history of a resource that spans multiple repositories. So if you deliver a specific version of a file to a customer, additional meta-data related to its version history is also transported so that at the customer site the full version history can be calculated. This is used to decide whether or not a conflict must be reported when the next version from SAP is received."
"Perforce has a linear revision history containing revisions in a single branch, right ?" she asked.
"Correct. Perforce uses what it calls 'Inter file branching', which means that when you integrate a file to a new branch, a new file is created. In DTR, this only results in another version of the same file."
"But Perforce does maintain the branching information, doesn't it ?"
"It does, but that is just a pointer from the source to the target branch. It does not keep track of subsequent integrates that were performed in both directions, and hence cannot indicate conflict situations correctly. For instance, back integration from a 'correction' branch to the 'development' branch always brings up a conflict, even though the development branch version was never modified."
"Oh ! So that's why we always had to do double-maintenance with our projects in Perforce ! If we could integrate in the reverse direction it could save us a lot of manual overhead!!"
"Yes." I smiled. "With DTR you can simply integrate your bug fixes of older releases into the new releases. A conflict is reported only if the file was modified in both workspaces."
"What are the other attributes related to this propagation functionality ?" She seemed more curious now.
"Another important attribute is sequence independent propagation. In a distributed landscape where there could be more than one provider of software - like SAP, and some partners of SAP - and more than one receiver of software - like SAP Partners and customers of SAP - the SCM tool cannot depend on the sequence of propagation. Current SCM tools which support propagation work on the assumption that if change A was done first, followed by change B, then these are transported and received in the same order."
"Hmmm..."
I was not too sure if she understood the importance of this functionality. I continued anyway.
"Also, the granularity of propagation should be flexible. With DTR, changes are grouped in 'activities', and these activities - which contain versions from a set of files and folders - are units of propagation. Additionally, we can select arbitrary versions into another unit of propation called a 'Propagation List', which can contain any number of versions of distinct resources." I looked at her to see if she had understood.
"So normally all changes recorded in activities are propagated, but we have the additional flexibility of choosing precisely what versions we want to propagate - is that it ?" she asked.
"Thats right."
"All this is fine, but if I remember correctly, ClearCase also has branches and supports merging across branches - right ?" She really was persistent.
"In ClearCase, a branch is something you create for every individual resource - there is no "global" branch which applies to all resources in a given code-line. This causes problems with administration and control."
"How ? I did not understand. "
"If you remember, a VOB in ClearCase is like a source tree. But each resource - a file or folder - in this source tree can have complicated version graphs, based on the branches created for each resource. (So in this sense a VOB is like a virtual repository). Now let us say that a bugfix for release X needs a modification of file F1, F2 and F3. This must be performed in a separate branch for each file. To keep things under control, ClearCase recommends to use the same branch name while creating branches for changes that belong together. If this is followed, then a ClearCase View can be configured such that elements on this branch are visible in the context of this view. Since this decision - of naming the branches for individual files - is left to the user ( or the person who configures the View ), it is not comfortable in organizations where centralized and automated control is important."
"What is a ClearCase View ?" she asked. I had used this term without explanation, and she probably liked to have a clear idea of everything.
"A View in ClearCase is like a 'Virtual Workspace', which provides isolation through access to a specific set of versions of distinct resources in a VOB. Think of it as a private storage - it allows different users to work independently on the same VOB."
"So when I create a View, can I select any version of a resource in a VOB ?"
"Yes you can. So if you want to work on a bugfix of a release X, then you can create a View by selecting the latest version from the Bugfix branch of resources which must be modified for this fix, plus the latest version from the Main branch of all other resources."
"That conveys a lot of flexibility, doesn't it ?"
"It does, but that turns out to be a disadvantage in our case. We want to have control over what versions our customers can see. If we do not have this control, then customers could define their own views to the repository and ignore versions shipped by SAP, which could frequently lead to inconsistencies in the state of the software."
"So how is this situation avoided when one uses DTR ?"
"DTR is well integrated into the Java Development Infrastructure of the Netweaver platform, and it is the Change Management Service - CMS in short - that creates and configures workspaces in a landscape. Once the workspaces - the codelines like Development, Correction, Consolidation - are created, things proceed in a controlled manner. So users cannot create workspaces on their own - they work on workspaces created and administered centrally. This applies to customer landscapes as well. So when an upgrade from SAP arrives, the workspaces - codelines, or branches - into which the changes must be integrated are known, and so we do not have any surprises after the upgrade."
"So if the upgrade contains a new version of a file which the customer has modified, a conflict is reported, right ?" she asked.
"That is right. Since DTR maintains a global version history, it can calculate - based on predecessor successor relationships in the version graph - whether or not a conflict must be reported. And of course, DTR provides tools to view the differences between the two conflicting versions, and merge them - either automatically or manually."
"That is fine. But assuming the customer resolves his conflict in his 'development' system - or workspace - then when the upgrade is imported into his 'consolidation' workspace, the same conflict will be reported there also, right ? So he has to resolve it there again ?"
"No. When you resolve a conflict in DTR, the merge arrow is persisted, and propagated along with the merged version that was created. So if you resolve a conflict in the 'development' workspace, and then integrate this change into the 'consolidation' workspace, the conflict in that target workspace will be automatically resolved due to the merge arrow that was also part of the integrated change."
"Sounds cool ! I get the impression that apart from covering the functionality offered by major SCM vendors, DTR addresses rather well the specific issues that arise in the development areas within the landscape of SAP and it's customers." She seemed convinced, finally.
"Quite correct. You've probably noticed that we follow the 'main-line' model for development, which means changes in all branches are periodically integrated back to the main code-line ( or branch ). This was adopted based on our experience - it was found that most of the development within SAP follows this pattern. Now if you look at the strategy adopted by Perforce - Inter File Branching - it becomes clear that they do not expect integrates back to the main line of development ( and hence their model does not support such integrates well enough ). That strategy is good when you create a branch to work on a related but independent area, like, for example, a branch for platform dependent development. Since platform dependent code of a product is placed into a different branch, it is not expected to be integrated back to the main branch ( which contains platform independent code ). Since most of the development in SAP does not follow this pattern, this strategy of Perforce is ill-suited for us."
"And the features needed to support delivery of software to customers - they seem to have been mostly ignored by leading SCM vendors !" She seemed a bit surprised that other vendors had not ventured in this direction.
"Again, this is specific to our requirement. Typical customers of SCM tools only want to use the tool to support their in-house development, and this need is met to varying degrees by different tools. As we saw, some tools like ClearCase are quite generic and flexible, but when it comes to our special requirements - like the support for regular delivery of sources to customers - they fall short of the functionality we need."
"It is clear now." she said, with a smile.
"Well, DTR is the result of years of experience with complex, distributed development landscapes. We learnt a lot from the predecessor of DTR - a versioning system called Mobile Application Repository ( MAR ) which is used by the Mobile Application Studio to store and version the CRM Mobile applications shipped by SAP. The MAR already contains a few of the features I've talked about, and having gone through the experience of building and productively using a large scale versioning system across a few releases has given us valuable insight into what works and what does not. Its a pity that SAP does not sell technology - otherwise DTR could have given nightmares to all major SCM vendors."
"Considering all that you have said, I'm beginning to think so too. But I still have one complaint - why such a name like 'Design Time Repository' ? It sounds so ... so technical, doesn't it ?!"
"Er..um..well..."
相关推荐
DTR-DS-BPSK UWB系统同步方案、电子技术,开发板制作交流
matlab正弦仿真代码NIST-DTR-雷达-目标-模拟器 介绍 NIST DTR 雷达目标模拟器是一种应用程序,它使用正弦波模拟道路上移动的车辆,目的是测试雷达枪的准确性。 该应用程序允许输入有关车辆的可变数据 - 例如速度和...
For Philippine Government Employees
AC-DC控制器和稳压器_L6599DTR_规格书_ST(意法半导体)AC-DC控制器和稳压器规格书,中文数据手册,适合硬件电路设计开发人员使用。
就医管理系统java源码覆盖需求发现 (CRD) 参考实现 (RI) 覆盖需求发现 (CRD) 参考实现 (RI) 是一个软件项目,它符合由 . CRD RI 项目是可以模拟 CRD 交换中涉及的所有系统的软件。 该项目的主要组件是服务器,它充当...
动态张量再实现(DTR)原型 DTR作者:Marisa Kirisame,Steven Lyubomirsky,Altan Haan,Jennifer Brennan,Mike He,Jared Roesch,Tianqi Chen,Zachary Tatlock 存档内容 该档案包含以下内容: data_files :从...
dtr-system 一个基于SpringBoot的学生老师预约课程(辅导)平台,前端逻辑主要用Jquery、BootStrap、template等插件构成 主要功能 用户模块 用户登录功能: 用户根据自己的学号和对应的密码登录到系统中 密码重置...
它提供了出色的输出
Debian 测试 Remix 基于带有 JWM 的 debian 测试和一些用于构建您自己的操作系统或用作 livecd 恢复的有趣软件。 程序包括 Ailurus 漂白位 gparted gparted grub 定制器 SystemBack(livecd 来创建自己的操作系统)...
Create React App入门 该项目是通过。 可用脚本 在项目目录中,可以运行: yarn start 在开发模式下运行应用程序。 打开在浏览器中查看它。 如果进行编辑,页面将重新加载。 您还将在控制台中看到任何棉绒错误。...
基于输电线路有功功率损耗的软DTR实现,汝绪丽,陈芳,通过直接估计输电线路电阻实现软DTR功能,存在难以精准把握的问题,因而提出了将输电线路最高允许温度转化为有功功率损耗的限制,
超宽带通信系统同步的精确度是影响系统性能的关键问题,为减少差分传输引导波超宽带通信系统同步算法的 平均捕获时间和提高同步算法的精确度,设计了一种变换同步算法积分区间和门限值比较法相结合的帧级快速同步算 法...
/dev/ttyS1 9600 8n1 +dtr -rts -cts -dsr send [hex](52)(30)(31)(d)[ascii][pause] wait 0.500000 seconds [hex](82)(48)(49)(13) wait 0.500000 seconds read 8 characters 0.2910 $ Notes * \h toggles hex/...
FHIR 应用程序上的 DTR SMART 这个子项目包含一个 SMART on FHIR 应用程序,它提供了一种与 FHIR 服务器交互的标准化方式。 此参考实施 (RI) 支持 ,它指定如何在提供者上下文中执行付款人规则以确保满足文档要求。...
【时钟发生器】MK1707DTR(25-108MHz).pdf
dtr - DTrace Runner Node.JS 封装了有用的 D 脚本以降低使用 DTrace 的门槛 安装 先安装 ,再安装dtr [sudo] npm install -g dtr 如何 只需运行dtr即可获得要运行的脚本的交互式菜单 dtr将显示按部分细分的 D ...
在RS-232定义中,TXD-RXD, DTR-DSR, RTS-CTS 为三对主要的收发信号线,另外还要连接GND(地线)。而Modem属于DCE(数据载波设备),DCE与DTE之间连接使用直连电缆,即DTE的TXD接DCE的TXD,RTS接RTS, CTS接CTS.... RJ-45...
PC串行口DTR_RTS信号的特殊用法
dtr.http-github.io-
74HC244DTR2G数据手册(ONSEMI公司)-