PowerBuilder 11.5 和版本控制答案

【问题标题】：PowerBuilder 11.5 & Version ControlPowerBuilder 11.5 和版本控制
【发布时间】：2009-07-01 13:49:09
【问题描述】：

使用 PowerBuilder 11.5 实现的最佳版本控制系统是什么？

如果您有示例说明如何进行分支/主干/标记，那就太棒了。我们已经尝试过几次，但总是遇到问题，因为我们在多个应用程序中使用了 PFC/PFE 等共享库。

现在我们只使用 PBNative，而且很烂。

【问题讨论】：

标签： version-control powerbuilder

【解决方案1】：

Agent SVN 是一个 MS-SCCI Subversion 插件，可与 PowerBuilder 配合使用。

这里是 a link，它描述了如何设置 Agent SVN 以使用 PowerBuilder 和 Subversion。

【讨论】：

【解决方案2】：

我们目前使用Perforce，它是P4SCC 插件，效果很好。事实上，我确信我在某处读到过，Sybase 中编写 PowerBuilder 的人实际上自己也在使用 Perforce。

【讨论】：

您是否使用其他任何东西来管理分支/标记？我听说过很多关于使用 Tortoise 的信息，但如果非必要，我不想使用它。
不，所有的分支工作都在 Perforce 的图形界面 p4v（或通过 p4 命令行界面）内进行，它非常简单，是迄今为止我遇到的最好的源代码管理工具
它还有一个出色的差异/合并工具 p4merge
你肯定在让我向它倾斜。我刚去看了它的演示，它看起来真的很不错。

【解决方案3】：

所以，公平地说，让我们首先说当您询问版本控制时，PBNative 是源控制。如果你比较的东西打算有更多的功能，而不仅仅是阻止两个开发人员编辑同一个源代码，那么是的，PBNative 会很糟糕。 Madone SL 可能是一辆令人难以置信的自行车，但如果您想在印地赛道上绕几圈，那就太糟糕了。

“最佳”是一个相当主观的词。版本控制和配置管理工具中有很多可用的功能。您可以获得大量功能，但您会付出代价。 StarTeam 有一些不错的功能，例如能够跟踪客户端更改请求或错误报告一直到更改的代码，以及能够链接到定制的差异工具（这在 PB 中特别有用）。再说一次，如果成本是您的关键标准而不是功能，那么有很多免费选项可以完成工作。只要该工具支持 Microsoft SCC 界面，就应该没问题。

有一个相对活跃的 NNTP 新闻组，专注于使用 PowerBuilder 进行源代码控制，您也可以通过 web 访问该新闻组。您可能可以在那里找到一些已经发布的意见。

【讨论】：

【解决方案4】：

多年前，我使用 Starteam 来控制 PB 应用程序。 PowerBuilder 不用说是一个过时的熊，它必须将每个对象从它的“库”导出到源代码控制中。目前我们的旧版 PB 应用程序将其库全部保存到 Subversion 中，不支持 diff 等。

【讨论】：

我们在 StarTeam 方面取得了巨大成功。它还允许您定义 3rd 方差异工具。 PBDelta 是区分 PowerBuilder 库 (PBL) 文件的首选工具：pbdr.com/software/pbdelta.htm
这是因为 PB 将源代码和编译版本都存储在 PBL 中。使用 IDE 运行时无需进行编译。

【解决方案5】：

我们使用 Visual SourceSafe。我们不使用 PFC，但我们确实有在多个项目之间共享的库。到目前为止，每个项目都是独立开发的，因此共享库是重复的。为了使它们同步，它们都在 VSS 级别共享。最近我们重新组织了我们的资源，所以所有项目都彼此靠近，并且只有一个共享库的实例。

VSS 绝对不是最好的源代码控制系统，至少可以这么说，但它集成到 PB 中而不需要任何桥梁。 PB 在使用源代码控制时存在一个固有问题，因此使用其中一个而不是另一个可能不会有太大的不同（至少从 PB 的角度来看）。

现在，就个人而言，我想说 PB 11.5 是一团糟。它不断地崩溃，充满了令人难以置信的 UI 滋扰，只会让生产力崩溃。这可能是有史以来最糟糕的 IDE。尽可能远离。

【讨论】：

老兄，我对你有感觉。 PB11.5和VSS？生活一定很糟糕。
哦，确实如此……但源代码控制是我们最不关心的问题。到目前为止，PB 是我们开发环境中最糟糕的部分。我的英语不够好，不足以表达我对 Sybase 用 11.5 所做的工作的鄙视。
很抱歉听到您的挫败感，我在新的 PB.NET 上工作并且没有参与 11 或更早的版本（无罪）。我希望我们用新版本能给大家一个更好的印象。目前我们处于测试阶段。

【解决方案6】：

仅供参考：新的 PB12 (PB.NET) 将与 SCC 系统集成，因此您可以轻松选择要使用的源代码控制系统。由于我们基本上已经删除了 PBL（它们现在是目录）文件可以单独签入/签出 - 即使使用普通的 vanilla 编辑器，因为文件现在是普通（unicode）文本文件。

【讨论】：

旧版本的PB也支持SCC接口。我已经将 PB9 与 Perforce 一起使用。
我相信他们所说的是这些对象不再位于 PBL 中。每个对象都在一个文件中。这个想法是任何版本控制系统，不仅仅是符合 SCC 的系统都可以工作。

【解决方案7】：

StarTeam 与 PB IDE 完美集成。我在以前的公司（PB9 和 ST5.x）使用了这种组合好几年了。您应该在对象级别管理您的代码 - 不要将整个 PBL 记录到 ST...

如果您在使用该设置时遇到问题，请离线联系我。 sybase dot com 的 phoran。

【讨论】：

【解决方案8】：

我们将 Merant 版本管理器用于较旧的项目，将 TFS 用于较新的工作。我们唯一的问题是 TFS 不支持关键字扩展和改变人们“阅读花盒 cmets”的态度。有些人担心丢失内联版本控制历史。

【讨论】：

【解决方案9】：

我们使用 StarTeam 并对此非常满意。它结合了错误跟踪和版本控制。不幸的是，尽管我们没有将文件存储在对象级别。我们只是将 PBL 文件直接存储在源代码管理中。理论上任何支持 SCC 接口的东西都应该在 PowerBuilder 中正常工作。

【讨论】：

【解决方案10】：

PB9：我们使用了 PVCS，但存在 pbl 损坏的稳定性问题以及与更高版本的 Crystal Reports 共存的问题（dll 冲突），因此现在我们将 PB9 与 Dynamsoft 的 Source Anywhere Standalone 一起使用。这个系统比较原始；它缺少用于提升级别和提取所有对象的旧里程碑版本以进行补丁构建的更高级功能。

我们现在正在寻找的是允许更高级的“变更管理”的东西，以支持变更级别（而不是对象级别）的提升级别。使用 perforce、starteam 或 (harvest change manager + HarPB) 或其他东西会更好吗？对于这些组合的任何建议将不胜感激。

【讨论】：

【解决方案11】：

您始终可以使用Plastic SCM with PowerBuilder through SCC。塑料在图形、工具、复制品等方面相当先进，因此始终牢记它是一个不错的选择。

【讨论】：