CN1965295A - 发布管理方法 - Google Patents

Abstract

软件体的增量分发是通过在计算装置上使用自动工具来执行的。该工具具有对包括要发布的软件整体的文件(该文件包括软件整体的最新发布)的访问，以及对存储详细资料的组件数据库的访问，其中所述详细资料包括但不限于文件(该文件包括包括在该发布中的每个组件的内容)的名称、组件、以及时间/日期标记。该工具知晓需要发布的更新的组件组，但仅在检查包括在没有更新的组件中的文件组中每个文件与最新发布以后没有改变的文件组中同一文件相同后发布软件，新的或自从最新发布以后已经改变的文件组与包括在被更新的组件中的文件组相同，且所述文件组中的包括要发布的软件整体的每个文件还仅包括在一个组件中。该工具还更新作为软件发布的部分的每个组件和每个改变的文件的构件数据库。

Description

发布管理方法

本发明涉及操作计算装置的方法，具体涉及用于以下面的方式操作这样的装置的方法，该方式允许多个程序员创建和分发(distribute)可定制软件产品的构件(parts)或组件(components)，同时相对地保证可由这些构件或组件组装成完整和相关的整个软件产品。

可定制软件产品可定义为这样的软件，其中接受者接收所有或部分用来和相应二进制码或可执行码(executable)一起构成软件产品的源代码，从而使得接受者能够按照其自身的需要修改软件。

可定制软件产品的定义包括开放源码软件和自由软件。其也包括这样的产品，其中源代码的接受者和软件包括受限组。例如，由Symbian Ltd of London开发的Symbian OS操作系统是可定制软件产品，因为操作系统授权的接受者接收所有或部分用来和相应二进制码或可执行码一起构成软件产品的源代码，从而使得接受者能够按照其自身的需要修改软件。

当基于规则发布(release)连续开发任何软件体时，通常在每个发布中只对软件整体的某些部分做相对小的改变；即，从一个发布到下一个发布，软件体的大部分通常保持不变。

然而，为了确保所有发布的接受者的一致性和均匀性，经常每次发布都整个地将软件整体全部地重构和再分配。这通常是通过将安装文件拷贝到物理介质上，如CD-ROM或其它非易失性存储介质，或通过使安装文件可经因特网或其它数据传输介质下载而获得来实现的。所有原始软件文件，甚至是自从该软件的任何之前的发布以来未曾改变的那些部分，也都被包括在该更新中。然而，对于大软件体，如计算装置操作系统，这对于每次发布可能意味着不必要的大量CD-ROM的分配，或如果将因特网用于下载的分配，则需要许多小时甚至多天的连接时间来下载文件。

这种传播(disseminating)关于软件体的改变的方法通常被称为整体分发(monolithic distribution)。其主要优点在于每次都有效地整体构建软件，其提供公共基准平台，该基准平台实质上保证为所有接受者服务，而无论任何接受者如何修改了先前的发布。该分发方法通常被当作最常用的发布任何类型软件更新的方法。

一种用于分发更新的软件发布的可选方法是独立于整体，仅分发在功能上与先前版本不同的软件的那些构件，然后接受者按需要重构软件整体。该传播改变的方法可称为增量分发(incrementaldistribution)。其最明显的优点是比整体分发更快并更高效，这是因为对于每个发布仅需要分发较少量的数据。其它重要优点源自这样的事实，即增量分发依靠将软件整体分成多个独立构件，通常称为组件，组件的存在使得接受者能够保留尽可能多的在修改先前发布中所做的投入。增量分发以下面的两种方式使得能够实现上述情况：首先，因为其精确分发更新软件产品所需的部分，其次，因为接受者可选择性地决定丢弃他们各自的对软件产品的定制所不需的任何组件更新。

the Computing Laboratory at Oxford University的Colin Percival已经编订了软件更新的再发布和分发的综述(overview)。可在http://www.daemonology.net/freebsdupdate/binup.html找到该综述，其概括了该领域中的众多问题和困难。然而，Percival没有找到适用于如上所述的可定制软件产品的任何方法。该综述中描述的两个表面上相似的公知的软件更新方法值得在这里详细说明：

●存在用于部分发布的整体分发方法，该部分发布不包括可定制的源代码。具体地，微软通过发布(issuing)服务包而不是重新发布软件整体，来更新其操作系统和软件套件，这些服务包不同于完全重新安装之处在于它们保留了用户对问题软件的定制。

然而，这样的服务包发布不在本发明寻求解决的问题范围内，因为要应用服务包的微软产品不能被当作可定制的软件产品。最重要的是，没有源代码包括在服务包中或分发给用户。因此，用户不能修改软件源代码，以便按自身需要定制软件产品；用户仅能够在产品设计人员和作者允许的范围内定制产品的行为。特别地，当安装服务包时，对更新过程没有控制，且用户不能决定服务包任何部分的实际选择性的采用。

●也存在Linux分发所用的方法，其能使接受者将分开的组件更新集成到操作系统中。这些方法中最公知的是基于Debian包管理器(关于Debian Linux组件化的更多信息请参看http://www.debian.org/doc/debianpolicy/ch-binary.html)和由Red Hat开发并被Linux Standard Base项目采用的RPM系统(关于RPM包管理器的更多信息请参看http://www.rpm.org/)。

然而，这样的包管理系统也没有落在本发明寻求解决的问题范围内。这是因为诸如Red Hat的公司和诸如Debian的组织自己并不制造可定制的软件产品。他们所做的是聚集并集成来自多个源和作者的独立和分开的可定制的软件产品，并将这些独立制造的组件以接受者能成功集成它们的方式进行打包。Linux分发不需要提供任何关于发出时的软件整体和它们组件发布的接受者可使用的软件整体之间关系的保证。

因此，将其软件作为集成的整体来设计、编写和构建的操作系统作者和经销商必须描述(delineate)然后管理组件，这种方式与Linux销售商接受和重新分发组件的方式存在明显的不同，例如Linux销售商组装来自于由其它人制造的可定制软件产品的操作系统，且不需要增量更新软件整体，这些软件以一致和连贯的方式发送。

从上面的描述可以理解，整体分发的主要优点在于其本质上保证为所有接受者服务，而无论他们是如何修改以前的发布的。

图1用图示了整体分发。然而，由于以下几个原因该方法还存在缺陷，这些原因包括：

●分发软件的改变和未改变部分是低效、昂贵和不便的。在特定发布的改变非常小时尤其如此，所涉及的数据量非常大，且分发渠道能力有限。可定制软件产品通常包括大量数据，这是因为源代码是与二进制代码一起分发的。在如Symbian OS操作系统的情形中，通过中等带宽数据连接在线传输全部数据可能需要几天的时间。

●整体分发策略所产生的一致性和均匀性要求要求软件体应按照标准策略制造，理想地，在同一地点和同一时间由同一组人完成：实际上这通常表示相当大的开发瓶颈。

●由于分发(distribution)没有被分成组件，并且由于无差别地包括了软件的改变部分和未改变部分，因此，对于接受者，没有一种容易的方式选择所想要选择的那个分发组件；分发没有被分成接受者可以从中选择的分离组件。例如，假定对特定设备驱动器的更新是特定接受者所要求的全部，那么接受者将不得不试图分解整个分发并分析其内容，以便仅抽取构建所需设备驱动器所需的那些部分。当然理论上这是可行的，这是由于分发不包括完整的源代码和构建信息。但是，很可能分发中的改变足够复杂，以至于在合理的时间段中成功的机会非常小。因此这样的接受者可能必须接收所有包含在该发布中的更新，无论它们是否都是需要的。

当增量分发克服许多由整体分发所产生的困难，并因此提供潜在的速度和效率方面的收益时，它就会产生自己的影响。

增量分发在某些方面比整体分发具有更高的潜在风险，其原因在于因为仅分发部分源代码，所以软件制造商更有可能出错。对于大的软件体，如操作系统特别是这样。例如，可能从发布中意外地忽略了增加的源文件(是新的而不是未改变的)。或，组件之间的相互依存关系非常复杂时，任何一个组件发布失败都会导致接受者发现源代码或头文件可能在发布中以多种版本存在。

另一个风险源来自于增量分发吸引软件接受者的原因之一，也就是接受者能够基于实际需要和使用挑选并选择所要的组件。因此，作者和分销商将面对他们的产品将由不同接受者以多种不同配置使用的近乎必然性。作者和分销商无法辨别是否任何特定模块已经被更新或定制，并且要面对这样的前景：每个接受者均构建成具有定制组件、更新组件和初始组件的独特混合的场景。这降低了其对产品质量的控制并增加了支持成本。

即使制造商在发布过程中没有犯错，且即使接受者采用了该发布中任何组件，增量分发也要承担额外的风险。因为其不是从“纯净”基础发布开始，该发布不能为作者或分销商提供如整体分发方法所提供的同等水平的保证；所有接受者精确构建相同版本的软件。这是因为是接受者而非作者或分销商负责合并新分发文件和旧分发文件，并然后重建软件体以供实际使用。

而且，构建过程的随机复杂性及其与特定和不可控制性大的用于重建的本地系统配置方面的依赖性如下：即不总能够对任何接受者保证重构软件整体的完整性。

此外，对于增量分发来说，软件体必须被划分成组件：如果软件仅能被整体构建，则不可能采用该方法。然而，对于熟悉本领域技术人员来说很显然，即使具有良好的模块化架构，将大的软件体划分为独立的可分发组件也不是件容易的事情。确定不同区域和组件之间的多种关系和依赖性是困难并耗时的过程。

而且，识别那些仅需要被包括在增量分发中的软件部分的实际工作不是微不足道的。手动尝试和优化该工作被认为是高风险的过程。关于手动工作，the Computing Labority of Oxford University的Colin Percival指出，“they all attempt to mininise the number of filesupdated，and they all include human participation in this effort.Thisraises a significant danger of error；even under the best ofconditions，humans make mistakes，and the task of determining whichfiles out of a given list had been affected by a given sourse code patchrequires detailed knowledge of how the files are built.(他们都试图最小化更新的文件数目，且他们都包括人类参与到该工作中。这增加了重大危险的错误；即使在最佳条件下，人类做出错误，且确定给定列表外的哪个文件被给定源代码补丁实现的任务要求有文件如何构建的详细知识。)”

关于最后一点，应该注意，虽然手动优化有风险，但是发布的自动优化也不容易实现。这是因为自动区分功能性和非功能性的改变相当困难。文件中非功能性变化的一个实例是附加到源代码的注释中的拼写错误已经被修正的情形。这样的修正明确地改变了源代码的内容，不过是以非功能性的方式。当重新编译该源代码时，将再次以非功能性的方式改变包含在相关目标文件中的时间标记(timestamps)。使用自动地检查文件差别(如“Diff”)的自动软件工具，和使用如提供文件摘要以打开未改变组件的方法，这都会将源代码和目标文件标记为改变的。随后的对增量分发的优化失败会导致分发不需要进行更新的项目。

然而，有些现有技术教导了关于如何最小化该影响。例如，Percival描述了一种用于避免二进制文件再发布的方法，因为内部时间标记已经通过从同一源构建文件而两次改变，但每次改变都有不同的系统日期，然后执行逐字节比较从而发现存储时间标记的位置。这使得在比较过去和当前发布时能够排除这些文件的范围，并因此在识别改变的组件时避免不能确定的结果。Symbian Ltd以前已经发布了一种称为“evalid”的工具作为Symbian OS操作系统的一部分，其执行文件的逐字节比较但忽略这些不重要的差别。然而，应该注意到对于识别需要被包括在更新中的那些部件这一问题的所有这些解决方案仍然依靠文件比较发挥作用。

图2图示出了由增量分发固有问题所产生的某些最终结果。通过比较增量分发模块与图1中所示的更简单的整体分发模块可清楚看到三个风险。图2的左手边部分100示出由软件制造商构建的二进制文件，图2的中间部分200示出所发布的组件，而图2的右手边部分300示出接受者以其结束的文件。改变的二进制文件由将它们连接到它们所属的组件的虚线指示。可以看到重新发布组件A失败导致二进制文件B1/A5存在于两个不兼容版本中；二进制文件E1根本没被包括在该发布中；且构建的组件中所用的二进制码D1与接收的版本不匹配。

从上面的讨论中清楚看到没有能够调和整体分发方法的优点和增量分发方法的优点的可行的方法。

因此，本发明的目的在于提供一种增量分发方法，其能够提供与整体分发方法相等的保证，以确保一套组件发布能完全并精确地表示软件整体。

本发明进一步包括增量分发方法的优化，其使得作者、分销商和接受者能够区分功能性和非功能性变化，这确保在发布中没有不需要的内容被分发，因此最大化效率和方便性。

根据本发明的第一方面，提供了一种方法。

根据本发明的第二方面，提供了一种计算装置，用于根据第一方面的方法进行工作。。

根据本发明的第三方面，提供了一种计算机软件，用于使根据第二方面的计算装置根据第一方面的方法进行工作。

下面将只参照附图，利用进一步的实例描述本发明的一个实施例，附图中：

图1图示出用于分发软件体的整体分发方法；

图2图示出软件体分发的增本方法；

图3图示出了可以如何在软件体的发布者和接受者之间设置软件体的组件发布；以及

图4图示出了如何检查发布开发驱动器上的每个文件，以查看其是否是与软件体的接受者共享的介质上的同一组件中的文件相同的一个。

在下面所述的本发明的实施例中，通过一组自动工具对组件进行发布且实施相对保障。为了本发明的该实施例的目的，做如下假设：

●构件发布是由本文中称为发布者(releaser)的个人或团队做出的，且假定发布者在自己的开发驱动器上具有自己的软件体副本。

●构件发布被送给本文中称为接受者的个人或团队，且假定接受者在自己的开发驱动器上具有自己的软件体副本。

●假定发布者使接受者可通过共享的介质，如计算机网络、FTP(文件传输协议)站点、或甚至是CD ROM获得软件。

●假定软件已经被分成组件，且存在某些类型的组件数据库或等效数据存储，且列出了这些组件、它们之间的关系、构建它们所要求的源文件、以及它们产生的二进制文件。为了方便起见，将这些数据库的副本可选地保存在共享的介质上，这是因为这使接受者能够将该数据库的相关部分复制至他们的用于每个构件更新的本地开发驱动器(development drive)上。

●假定在发布过程开始时，接受者的开发驱动器关于软件体的内容与共享的发布的驱动器的内容相同(接受者具有最新的软件发布)，且发布者开发商的驱动器的内容与共享发布的驱动器的内容不同(软件的最新发布不是当前版本，且需要新发布)。

图3中示出了这些关系。所使用的过程可概括如下：

a)发布者通过某些适当方法将软件体中已经改变的那些软件体组件和没有改变的那些组件通知给发布工具。所有改变的组件中所包括的文件包括已改变的文件组，如图3所示的R1。考虑到本领域的技术人员将会知道有多种传播该信息的可能方式，如通过在命令中传送能找到该信息的一个或多个文件的名称；不被认为用来实现该信息传输的正确方法对本发明具有重要性。因此，本发明可以适于以这些方法中的任何一个来运行。

b)然后发布者对工具发出命令，告诉它们对该工具现在知道的已经改变的组件进行新发布。可以通过该工具在如下部分处理过程中检查该发布的一致性和完整性：

i)如图4所示，检查发布开发驱动器上的每个文件，以查看其是否与共享介质上同一组件中的任一文件相同，或，如果其与共享介质上的不同或不存在于共享介质上，则查看是否被列为属于改变的组件组(图3中的R1)中的文件。如果这些检查中的任何一个失败，则该发布失败。

ii)还是如图3所示，检查发布者开发驱动器上的软件以确保每个文件只精确地被包括在一个组件中；即，没有文件被所有组件都忽略；且没有文件包括在一个以上的组件中。如果检查失败，则发布失败。

c)最后，该工具通过将改变的文件组(图3中R1)从发布者开发驱动器复制至共享介质上来发布最新版本的软件。

d)和包括在该发布中的实际文件一样，该工具也生成和发布构成已经改变的软件体的那些组件细节的元数据；这是基于由发布者在该过程开始时有效宣称的组件改变，通过更新带有信息的组件数据库实现的。如下面所述，该元数据被接受者用来从共享介质中提取增加更新。

应该注意，在Symbian Ltd使用的本发明优选实施例中，发布元数据也包含当进行发布时存在于开发环境中的其他组件的表单。单独根据新做的发布，加上先前的发布，结合有施加的条件的该“环境”信息使得能够在另一台计算机上重建任何发布的准确环境。

下面的伪代码更精确地描述该发布过程：

发布者伪代码

1 Releaser declares that certain of the installed components are‘pending release’with the declaration for each component includingeither a manifest of all the information comprising that component orelse the information needed to obtain such a manifest via the tools usedto build that component(发布者通过每个组件的声明来声明某些安装的组件“即将发布”，其中，该声明包括包括这些构件的所有信息的清单，或通过用于构建该组件的工具获得这样的清单所需的信息)

2 Releaser requests tools to make these component releases(发布者请求工具使这些组件发布)

3 Make list of files on Releaser Development drive-call it‘unknown origins’list(制作发布者开发驱动器上文件列表，其被称为“未知源”表)

4 Start with empty list of‘owned files’(从“拥有的文件”空列表开始)

5 Examine‘component database’to see what is installed(检查“组件数据库”从而查看安装了什么)

6 Foreach(installed component)(对于每个(安装的组件))

7 Set component status to clean(设置构件状态为干净)

8 Is component‘pending release’？(是“即将发布”组件吗？)

9 If no：(如果不是：)

10 Set component status to‘clean’(设置构件状态为“干净”)

11 Examine the originally-installed version of component，whichis still on the shared medium used for releases；get list of filesthat were included(检查仍在用于发布的共享介质上的组件的初始安装版本；获取所包括的文件列表)

12 If yes：(如果是：)

13 Obtain list of files belonging to component，from releaserdeclaration(从发布者的声明中获取属于组件的文件列表)

14 Foreach(file belonging to that component)(对于每个(属于该组件的文件))

15 Remove file from list of‘unknown origins’(从“未知起源”列表中删除文件)

16 Is file in list of‘owned files’？(文件是在“拥有的文件”列表中吗？)

17 If yes：(如果是：)

18 Abandon release(duplicate ownership)(放弃发布(备份所有权))

19 If no：(如果不是：)

20 Add file to list of‘owned files’(添加文件至“拥有的文件”列表)

21 Is file on the Releaser development drive？(文件是在发布者开发驱动器上吗？)

22 If no：(如果不是：)

23 Abandon release(missing files)(放弃发布(缺少文件))

24 Is component‘pending release’？(是“即将发布”组件吗？)

25 If no：(如果不是：)

26 Does file match the version that was originally installed？(文件匹配初始安装的版本吗？)

27 If no：(如果不是：)

28 Abandon release(dirty components)(放弃发布(脏组件))

29 Next(file belonging to that component)(下一个(属于该组件的文件))

30 Next(installed component)(下一个(安装的组件))

31 Are there any‘unknown origin’files left？(是否还有任何“未知起源”文件吗？)

32 If yes：(如果是：)

33 Abandon release(unknown origin files)(放弃发布(未知起源文件))

34 Foreach(pending release component)(对于每个(即将发布组件))

35 Create archive of release，for use by others(创建发布档案供其他人使用)

36 Record up-to-date filenames and timestamps in componentdatabase(在组件数据库中记录最新文件名和时间标记)

37 Next(pending release component)(下一个(即将发布组件))

38 Record with the release，the list of all components in‘component database’(随着该发布，在组件数据库”中记录所有组件的列表)

在上面的算法中，无论何时发布被放弃，发布者都需要在做另一次尝试之前修补引起该放弃的有关情况。优选地，继续检查进一步的错误而非放弃，而不是做出任何发布，该方式与在碰到错误时，代码编译器继续编译而非在发现的第一个错误处停止相同。这允许发布者减少为每次发布而重复的次数。

一旦已经做出发布，接受者利用其他的工具从共享的介质获得并安装新发布。该实施例的关键点是发布必须是通过上面的算法做出的；这绝对保证了没有间断、没有交叠、且没有构件不能由共享介质上的发布所复制。下面的伪代码中的算法假定接收者已有先前发布，并只请求自从先前发布以来的更新的组件。

接受者伪代码(1)

1 Recipient requests the changed entries in component databasesince the last release taken(接受者请求组件数据库中自从所做的最后一次发布以来的改变的项)

2 Foreach(changed component release in database)(对于每个(数据库中改变的组件发布))

3 Extract latest files of release onto recipient development drive(将发布的最新文件提取到接受者开发驱动器上)

4 Update recipient copy of the component database to record thecomponent version installed(更新组件数据库的接受者副本以记录安装的组件版本)

5 Next(changed component release in database)(下一个(数据库中改变的组件发布))

即使接受者已经漏掉了发布，该算法也一样起作用。假定在这样的情形中所有构件将被标记为改变的，对于没有采用任何先前发布的接受者和需要获得“洁净”发布的接受者，该算法也一样起作用。

在本发明的优选实施例中，在发布者伪代码算法的第26行有优化处理。该步骤表示本发明检查每个将要保持未改变的文件，在发布者开发驱动器上的版本与在共享介质上的版本相同。

该优化的基础在于可以数学方法来操纵文件中的数据，以产生表示该文件内容的单个数字、各种所称的信息摘要、散列(hash)或校验和。根据用来计算该数字的算法，两个文件具有同一信息摘要是极其不可能的。因此，可以比较两个文件的摘要而非比较文件自身，以便验证同一性。多个合适的算法存在于公众域，(publicdomain)中，如公知的MD5算法。将这些摘要和文件一起分发从而使得接受者能够校验同一性是通常的做法。

因此，本发明的优选优化中，建议在共享介质上的组件数据库中包含的信息中包括该组件中所包括的每个文件的重要部分的摘要，来为每个文件计算相似的摘要以保持不变、以及相互匹配这两个摘要以验证同一性。这种不是整个文件的而仅是文件的重要部分的摘要的分发，是本发明另一个有利的方面。可以理解，逐摘要的比较是比逐文件比较更快且更有效的方法，且为了正常工作，除了被检查的文件以外，不要求访问任何文件。在优选的实施例中，该方法如下：

●首先，检查文件以确定其格式。这通常可以通过读取开头几个字节而简单地实现。文件格式规定文件余下部分的结构，然后，对其进行检查以确定哪些部分被认为是“重要的”和哪些部分被认为是“不重要的”。

●决定什么是“重要的”的规则取决于操作的精确目的。对于二进制文件，最简单的情形是忽略那些简单重建文件(如时间标记)而改变的那些部分，这是由于只有表示文件功能的那些部分(如计算机机器代码)被认为是所关心的，因此是重要的。对于源文件，最简单的情形是忽略文件中所有注释和空白部分。决定哪部分是重要的的精确方法不是本发明的一部分；然而，其与例如由Percival提出的算法一起工作，以发现二进制文件中时间标记的位置。

可以有多种不同机制，用于传播识别每种文件格式的数据和用于为所有接受者确定重要区域的规则，例如，将格式描述包括在工具中或可选地将它们以工具可读形式存储在共享介质上。

●一旦识别了重要区域，则最简单的方法是将原始文件拷贝到另一个“虚拟”文件中。不重要的区域从该虚拟文件中略去。然后对该虚拟文件应用做信息摘要的(digesting)过程以产生摘要，该摘要仅表示文件的重要功能区域。因此，两个具有相同功能(即重要数据)文件之间的摘要将会相同，但在“不重要”数据之间的摘要将会不同。

●可以有各种快捷方式；例如，可以在所选择的原始文件部分上运行摘要程序而无需制作备份。类似地，可以存在快速得到的变换以产生仅文件重要部分的表示(例如传播可执行文件)。这些可用来减小执行复杂性以及节省执行时间。

与能使发布者有效地识别改变的文件一样，该优化还使接受者检查他们的软件体版本的完整性；它们可简单计算文件重要部分的信息摘要，然后检查与存储在组件数据库中的同一发布中的同一文件的摘要匹配的每个摘要。用于实现该功能的一种可能的算法如下：

接受者检查软件体

1 Recipient requests all the entries in component database for therelease to be checked(接受者请求检查用于发布的组件数据库中的所有项)

2 Foreach(component)(对于每个(组件))

3 Foreach(file in component)(对于每个(组件中的文件))

4 Compute message digest of significant sections of file as storedon recipient developer drive(计算如同存储在接受者开发驱动器上的文件重要部分的信息摘要)

5 Check that the digest matches the one stored in the componentdatabase for the same version of the same file(检查与存储在同一文件的同一版本的组件数据库中的摘要匹配的摘要)

6 If no：(如果不是：)

7 Report software may be compromised(报告软件可能受损)

8 Next(file in component)(下一个(组件中的文件))

9 Next(component)(下一个(组件))

我们认为本发明提供了以下典型的具有优于已知的分发软件体的方法的重要优点

●其提供了一种从一组独立的组件组装有保障的和连贯的软件整体-缺少上述的机制使得组件化的分发有相当大的风险，这正是许多接受者目前不愿意采用组件化文件而每次都只采用整个软件体的原因。

●其参与分发的发布；且不需要浪费时间和金钱来分发在单个地方由集中化的构建和整个团队产生的大量数据。借助这些有效保障的组件组，可在不同地方不同时间生产软件整体的多个部分，并为接受者提供其结果是完整和一致的明确保障。

●在发送嵌入式软件给多个接受者时，额外的灵活性显著减少了依靠软件开发产品所需的时间——使用公共的但定制的操作系统的移动电话的各种不同模块的开发是这方面一个很好的例子。

●在文件和组件实际已经改变时，使用文件重要部分的相对小的信息摘要，这使发布者和接受者可以对其进行快速和容易的检测，其中，该信息摘要易于存储和易于用来校验功能一致性。特别对于如操作系统的大软件产品，这在分发、采用和校验新发布的成本和时间方面能够产生数量级的差别。

●该方法可应用至任何数字或数值数据体，而非仅仅计算机软件文件。

尽管已经参照特殊实施例说明了本发明，但应该理解，可以对所附权利要求书所限定的本发明范围内的其余部分加以修改。

Claims (11)

1.一种用自动工具操作计算装置的方法，用于发布对包括多个组件的数据体的更新，该方法包括：

使得能够访问包括要发布的所述数据体的文件；

使得能够访问包括所述数据体的最新发布的文件；

通知发布一组更新的组件；

对于所述更新的每个组件，均使得能够访问包括所述文件的名称、组件、和时间/日期标记的组件数据库；

检查包括在那些没有更新的组件中的文件与所述数据体的最新发布中的相应的文件相同；

检查最新发布以来的新的或改变的文件与所发布的组件的相应文件相同；

检查每个要发布的文件仅包括在单个组件中；以及更新所述组件数据库。

2.根据权利要求1所述的方法，其中：

所述工具被设置成可访问包括已经发布的整个数据体的所述文件；以及

所述工具被设置成询问所述组件数据库，且仅采用所述发布中的自从所述数据的最新发布以来改变了的那些组件。

3.根据权利要求1或2所述的方法，其中：

用于所述数据体中的每个文件的所述组件数据库包括所述文件的仅在功能上重要的部分的信息摘要；

更新所述组件数据库的步骤包括：计算和存储每个改变了的文件的仅在功能上重要的部分的新信息摘要；以及检查包括在没有被更新的所述组件中的每个文件与先前发布中的同一文件相同的步骤是通过以下步骤来执行的：计算所述文件仅功能上重要的部分的信息摘要；以及检查其与存储在所述组件数据库中的文件的先前发布的摘要相同。

4.根据权利要求3所述的方法，包括通过以下步骤校验所述数据体的发布的完整性：计算每个所述文件中仅功能上重要的那些部分的信息摘要；以及检查这些信息摘要与所述组件数据库中每个文件的信息摘要相同。

5.根据前述权利要求中任一项所述的方法，包括复制、存储或更新关于所述数据体的信息到诸如网络化计算机存储盘的共享存取介质上；以及通过复制、存储或更新从所述共享存取介质中提取的信息来获取发布或对发布的更新的方法。

6.根据权利要求1到4中任一项所述的方法，包括复制、存储或更新关于所述数据体的信息到诸如计算机磁带或高密度盘或数字视盘的分发介质上；以及通过复制、存储或更新从所述分发介质中提取的信息来获取发布或对发布的更新的方法。

7.根据前述权利要求中任一项所述的方法，其中所有或部分步骤通过以用于模拟会发生什么的调试模式操作计算装置来执行，而不发布或获取任何数据。

8.如前述权利要求中任一项所述的方法，其中所述数据体包括用于计算装置和/或电信设备的操作系统。

9.如前述权利要求中任一项所述的方法，其中所述数据体包括数字或数值信息。

10.一种计算装置，其被设置来按照权利要求1到9中任一项所限定的方法操作。

11.计算机软件，其被设置成使根据权利要求10的计算装置按照权利要求1到9中任一项所述的方法操作。

Images