为什么要用DTR,而不是Perforce或ClearCase

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 ).

前几天，我和一位对软件配置管理工具（SCM）有深刻认识的同事进行了一段非常有意思的对话，主要是关于SAP的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 ?"

“我研究了一下DTR”，她说，“但我是始终不明白为什么我们还要建立我们自己的版本控制工具？要知道市场上已经有了非常成熟的软件版本控制工具，比如说Perforce或者是ClearCase，这些工具应用了很多年，并且早就被证实了在大型分布式项目开发过程中具有强大的管理功能。为什么还要重复这项技术呢？”

"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 ?"

“那我可想听听。”我的同事说。“对我而言，DTR跟Perforce很像——同样的文件或文件夹的检入检出模型，Perforce中的‘变更列表（Changelists）’类似于DTR中的‘活动（Activities）’， Perforce中的‘分支（Branches）’也类似于DTR中的‘工作空间（Workspaces）’。旧瓶装新酒，不是吗？”

"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- "

“那可是不一样的，等我慢慢解释给你听。但是说到活动（Activities）和工作空间（Workspaces），这两个术语来自于DeltaV标准。”

"What's DeltaV ?" she interrupted.

“什么是DeltaV？”她打断了我的话。

"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."

“DeltaV是WebDAV标准的扩展版本。WebDAV定义了通过Web存取和管理文件的标准方法。DeltaV增加了版本管理的功能，并且定义了与配置管理和版本控制相关的协议。如果用此标准来进行软件配置管理，就与SAP创建可修整（open-ended）系统的想法不谋而合。Perforce可没有采用这种技术。”

"That sounds okay, but it doesn't justify the development of a full blown SCM tool to meet this end !"

“听起来有些道理，但并不能要求所有成熟的SCM工具都去符合SAP的这个想法吧？”

"True. The reasons for that are different. You work with Perforce from Bangalore, don't you ? How fast is it ?" I asked.

“那是。这并不是开发DTR的原因。你还在班加罗尔（Bangalore，印度的硅谷）的时候就开始使用Perforce了吧？运行速度快吗？”

"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.

“非常慢！但是要知道Perforce的服务器在Walldorf，我们要通过WAN才能连接到服务器呢！”她倒是没什么怨言。

"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. "

“有道理，但是理应如此吗？我可不这么想。Perforc采用集中式服务器，他们称之为Depot，用于分布式开发，所有的用户，不论在哪儿，不论隔着多远，都得用这一个服务器。DTR可不一样。它可以对处于不同物理位置的库之间进行复制。也就是说，如果你在班加罗尔向远程的DTR服务器发送信息，在班加罗尔将会配置一个DTR服务器供你进行连接，同时，你所进行的操作也在远程的DTR服务器上，比如说位于Waldorf的服务器上进行复制，反向也是如此。”

"How does that work ?" she asked. "I mean, what is it in DTR which allows it to replicate sources in a way Perforce cannot ?"

“那是怎么实现的？”她问道。“我是说，DTR采用了一种Perforce不能实现的复制方式？”

"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."

“Perforce没有在分布式环境下对资源进行复制的概念。应用Perforce，对变更的整合可以同一个库中，不同的分支（brances）之间进行，而不能够在不同的库之间进行这样的操作。而DTR，类似的概念‘工作空间（workspace）’并不是指一个实体库，因而这种变更的整合可以在位于不同位置的库之间进行。如果目标工作空间（workspace）在位于另一地点的另一个库中，你只需要从源库中导出你所进行的更新，再导入到目的库中就可以了，变更已经被复制到了目标工作空间（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.

“没错，是好了很多。但是ClearCase不是老早就实现了支持复制的功能了吗！”她眼睛一闪，可能以为我会无话可说吧。

"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."

“的确如此。在ClearCase中，被称作VOB- Versioned Object Base, 实际上是库中的资源树。在某种程度上，比较类似于Perforce中的分支（Branch）和DTR中的工作空间（Workspace）。一个VOB可以分布在WAN上的不同地方，这是通过VOB的多个复制实现的，位于不同地点的不同用户都可以与复制的VOB共同工作。在定期间断的时候，就可以在复制的VOB之间进行同步操作，从而使得位于不同地点的复制的VOB的复制品得不同变更进行同步。”

"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."

“对于分布式开发，的确的。”我说。“但是SAP还有其他的需求，而ClearCase就不能满足了。最重要的是对于用户资源传送的支持。你应该知道，SAP能够将请求传递给客户，以供客户进行修改。因而我们希望软件配置工具（SCM）能够具有一些重要特性，以支持资源传播给客户的功能。”

"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.”

“首先，这个工具必须支持早期交付，客户的修改不会被覆盖。唯一的实现途径就是能够自动地发现在任何传播过程中的冲突状态。DTR可以进行全局版本历史，也就是跨越多个库的版本历史的维护。如果向客户发送一个特定的版本，与该版本历史纪录相关的数据也同时被发送，从而使得在客户端所有的版本历史都被记录。这个功能用于判断当SAP发送的下一个版本被接收时，是否必须记录冲突。”

"Perforce has a linear revision history containing revisions in a single branch, right ?" she asked.

“Perforce有线性变更记录的功能，能够记录在同一个分支（branch）中的变更，是吗？”

"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."

“是，Perforce的这个功能叫做‘内部文件分支（Inter file branching）’，是指当向新的分支中集成文件，将产生新的文件。在DTR中，只是产生一个新的版本。”

"But Perforce does maintain the branching information, doesn't it ?"

“但在Perforce中也的确维护了分支信息，是吗？”

"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!!"

“噢，那就是为什么我们在使用Perforce做项目时，总是需要进行双重维护！如果可以进行反向整合，就能够减少很多的手工工作！”

"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."

“是，”我笑着说。“使用DTR，就能够很简单地在进行系统调试时，将老版本的信息整合到新版本中。只有当两个工作空间中的内容同时进行修改时，才产生冲突报告。

"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."

“另一个很重要的属性是独立传播。在分布式环境下，可能会有多个软件供应商，比如SAP，以及SAP的其他合作伙伴，也会有多个软件的使用者，比如SAP的合作伙伴，和SAP的客户，在这种环境下，SCM工具不能依赖传播的顺序。目前SCM工具能够支持传播的功能，都是基于假定首先对A进行变更，随后是B，传送和接受也都是同样的顺序。”

"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.

“也就是说，传播的颗粒度要非常灵活。应用DTR，变更依据‘活动（activities)’进行分组，这些活动，包括文件和文件夹的不同版本，就是传播的单位。此外，我们可以选择任意的版本加入到另一个传播单位，我们称之为‘传播列表’中，传播列表可以包括任意数量的版本。”我看着她，想知道她是否听明白了。

"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.

“也就是说，正常来说，所有在活动（activities）中记录的变更都被传播出去了，但是我们也可以精确地选择我们希望传播出去的版本，增加了灵活性。”

"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.

“这些功能还真不错。但是我记得ClearCase也有分支（branches），并且支持跨分支的合并，对吗？”她还真挺坚持。

"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."

“在ClearCase中，分支是对每一个单个的资源而言的，而没有‘全局’的分支能够应用所有的资源在一个被选定代码分支，这将会给管理和控制带来麻烦。”

"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."

“你还记得吗？ClearCase中的VOB类似于一颗资源树。但是每一个资源，一个文件或是一个文件夹，在这棵资源树中都对应于很复杂的版本图，这些版本图是基于对每个资源所创建的分支。（这么看起来，VOB像一个虚拟库。）现在，假设对于版本X的系统调试需要对文件F1，F2和F3进行修订，就必须对每一个文件在独立的分支中进行操作。为了便于监控，ClearCase建议对于相关修改的分支创建，使用同样的分支名。按照这个建议定义的ClearCase视图，分支中的所有要素都能够在视图中被监控到。但是由于这个动作，就是对每个文件分支进行命名的工作，就需要用户，或者是定义视图的人来做。强调集中的组织并不喜欢这种做法，他们更希望实现自动监控。”

"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.

“什么是ClearCase视图？”她问道。刚才我用到了这个名词，但是没有加以解释。看来她是要打破砂锅问到底了。

"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."

“ClearCase中的视图类似于‘虚拟工作空间’，它可以在一个VOB中对资源、版本进行独立存取。你可以把它看作是私人的储物间，它允许不同的用户在同一个VOB中进行各自独立的操作。”

"So when I create a View, can I select any version of a resource in a VOB ?"

“也就是说，当我创建一个视窗时，我就可以选择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."

“是。如果你想对版本X进行系统调试，你可以系统调试分支的最新版本，也就是已经记录了你这次调试的最新的修改版本，和其他所有资源中主分支的最新版本中进行选择，以创建视图。”

"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."

“的确是，但对我们来说也有一个缺点。我们希望能对客户所能看到的所有版本进行控制。如果我们不能加以控制，客户就能够对库定义他们自己的视图，而不去管SAP的版本，这将会带来系统的不一致。”

"So how is this situation avoided when one uses DTR ?"

“那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."

“DTR与Netweaver平台的Java开发基础架构（Java Development Infrastructure）有很好的集成。变更管理服务（Change Management Service），就是CMS，在系统环境中创建和配置了工作空间。一旦工作空间，类似于开发、更正、集成这样的代码行，被创建，监控就自动开始进行。所以，客户不可能创建他们自己的工作空间，工作空间都是被集中地创建和管理的。在客户环境中也是如此。因而当进行SAP系统升级时，工作空间，包括代码行和分支，中的所有变更都一清二楚，一切都在掌控之中。”

"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."

“是，由于DTR维护全局版本的历史，它能够基于版本图中的前后关系进行计算，从而决定是否需要报告冲突。当然了，DTR提供了识别两个冲突版本中不同的工具，并且自动或人工合并这两个版本，”

"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."

“不是，在DTR中，如果已经解决了冲突，合并的冲突点被记录，伴随这个合并版本将创建传播。如果在开发的工作空间已经解决了这个冲突，在与合并的工作空间进行集成时，由于合并的冲突点也是整合变更的一部分，目标工作空间中的冲突将被自动解决。”

"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.

“听起来真不错！也就是说DTR除了涵盖主流SCM的功能外，还针对SAP及其客户的开发环境解决了特定的问题。”她终于相信了。

"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."

“非常正确！你已经发现我们沿用的是'main-line' 的开发模型，也就是说所有分支中的变更定期地回归集成到主代码行（或者是分支）。基于我们的经验，SAP中的大部分开发都是采用的这种方式。但Perforce采用的策略，内部文件分支（Inter File Branching），并不希望支持回归到主代码行的集成（当然，他们的这个功能也不是很好）。好处就是，对于一个相关但独立的空间创建分支（比如对于平台相关开发的分支）时，这种策略是非常必要的。由于产品的平台相关代码被记录进了不同的分支，因而不希望发生回归到主代码（包括平台独立代码）行的集成。由于SAP中的大部分开发不是采用的这种方式，因而Perforce中的策略就不太合适了。”

"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.

“还有支持软件传送到客户的功能，这个功能也被主流的SCM供应商忽略了！”她看起来对于为什么别的供应商会忽略着这么重要的功能表示非常吃惊。

"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."

“别忘了，这可是我们的特定需求！SCM工具的典型客户只是想应用这个工具进行内部开发，不同的SCM工具能够不同程度地满足这项功能。在我们看来，象ClearCase这样的工具非常地好用而且灵活。但是对于我们的特殊需求，比如对于定期从资源的客户传递的支持，这些工具还是存在一些问题。”

"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."

“DTR是多年来复杂分布式开发环境的经验积累。从DTR的先行者，叫做移动应用库（Mobile Application Repository，MAR )的一个版本管理系统中我们学到了很多经验。MAR被移动应用工作室用来存储由SAP系统传递过来的CRM移动应用。MAR已经包含了我们刚才提到的很多功能，它检验了建立和使用大规模版本管理系统的经验，带给了我们非常有价值的观点。非常遗憾，SAP并不卖技术，否则的话DTR的出现将是所有SCM供应商的噩梦。”

"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 ?!"

“想一想你今天的话，我也有了同样的认识。但是我还是有些想法，为什么叫做设计时间库（Design Time Repository）？听起来太技术了些，是吗？”

"Er..um..well..."

“呃，有些道理…”