65.9K
CodeProject 正在变化。 阅读更多。
Home

配置 Plastic SCM 数据库后端

starIconstarIconstarIconstarIconemptyStarIcon

4.00/5 (1投票)

2008年1月20日

CPOL

4分钟阅读

viewsIcon

24619

配置 Plastic SCM 数据库后端

引言

Plastic SCM 是新一代的版本控制工具。 它似乎完全用 .NET/Mono 编写,并为 Linux 和 Windows 开发人员提供了许多有趣的功能(不用说它对于多平台环境有多好)。

但今天我不打算讨论版本控制问题,而是讨论如何配置 Plastic 数据库后端。

Plastic 将所有版本化的数据存储在标准数据库后端中,这非常有趣,因为现在没有人希望将其重要的业务数据存储在某种笨拙的专用存储中……我的意思是,您的客户会允许您将他们的业务应用程序数据存储到专门设计的文件存储中,还是会要求您使用 MySQL 或 SQL Server 或其他东西? 好的,想想 SVN、CVS、SourceSafe……是的,它们可能是开放的,但是,您真的可以使用标准工具查看数据吗? 您可以选择更适合您特定需求的后端吗?

默认数据库配置

好吧,当您第一次安装 Plastic 时,它将使用 Firebird 数据库后端。 如果您在 Windows 上运行,默认情况下它将使用嵌入式 Firebird 服务器。 服务器启动后,您将看到创建了三个数据库文件:检查服务器目录中的 *.fdb,并检查您有多少个。 您始终会有一个 repositories.plastic.fdb,其中包含有关所有已创建的存储库的信息,workspaces.firebird.fdb 包含有关可用工作区的信息,最后,对于您拥有的每个存储库,都会有一个 rep_xxx.plastic.fdb

firebirddatabases.png

您可以使用类似 "ibmanager" 的东西来查看数据,但您首先必须停止 Plastic 服务器,否则默认的 Firebird 嵌入式服务器将保持文件锁定。

自定义数据库后端

我提到数据库文件默认在服务器的安装目录中创建。 好吧,这对于试运行来说可能足够了,但通常情况下,您希望将这些文件保存在专用目录中,以便于备份。 你会怎么做?

在服务器目录(loader.exe 所在的目录,如果您运行的是 preview 2.0 或更高版本,则为 plasticd.exe)中创建一个 db.conf 文件,内容如下

dbconf.firebird.png

请注意,该文件指定了三件事:提供程序类型(稍后会详细介绍)、连接字符串(.NET 或 Java 开发人员会非常熟悉)和数据库路径。 如果您将 param 留空,则将使用默认值。

提高性能

如果您曾经使用过 Firebird,您就会知道服务器的性能实际上比嵌入式的更好。 因此,让我们尝试更改它,以使 Plastic 服务器运行得更好。

下图显示了如何设置外部 Firebird 服务器连接,以便 Plastic 服务器将使用它而不是嵌入式的。 请注意,ServerType 现在为 0 (1 用于设置嵌入式服务器)。

dbconf.firebirdserver.png

后端配置非常灵活,如果您担心可扩展性或性能,这一点尤其重要。 如果您想在已经拥有强大的数据库服务器的内部网络中部署 plastic 服务器怎么办? 您可以在一台计算机上运行 Plastic 服务器,并在另一台计算机上运行数据库服务器,这通常会提高性能。 下图描述了该场景。

firebirdserverdeployment.png

以及,您将如何设置它。 检查以下 db.conf,并注意如何轻松调整服务器、端口和一些其他 Firebird 参数。

dbconf.firebirdexternalserver.png

输入 SQL Server

plastic 服务器最不为人所知的功能之一是它不受 Firebird 数据库的约束,它也可以使用 SQL Server。 Plastic 可以使用 SQL Server(2005 或更高版本,请务必注意这一点,因为它需要设置一些仅在 2005 及更高版本中可用的事务参数),这对于已经使用 Microsoft 的 DB 软件的公司来说更好。

设置 SQL Server 后端也通过更改 db.conf 文件来完成。 查看下图以了解如何设置它。

sqlserverparams.png

重要的是要注意,切换数据库后端不会将数据从一个数据库迁移到新的数据库,而只会告诉 plastic 开始针对新的后端工作。 如果您想迁移旧数据,则应使用一些标准应用程序在所需的后端之间移动数据,或联系 plastic 的支持人员。

结论

能够更改版本化文件所在的后端为您提供了更大的灵活性,并能够设计更好的 SCM 基础架构。

历史

  • 2008 年 1 月 20 日:初始帖子
© . All rights reserved.