GIT或？的大规模传统Powerbuilder

Question

我正在为我们的遗产评估各种版本/源代码控制选项 Powerbuilder应用程序（现在在PB11中，将迁移到旧版12 不久）。到目前为止，所有版本控制的源都非常有限 控制已经在内部完成，代码可以在其中进行更改 众多的旅游顾问，但这些变化往往被推入 某些模块代码所有者的基础。这个工作流程没问题 当公司虽小，但随着我们的成长，它变得越来越多 更具挑战性。这是一个非常大的应用程序。我会给你的 数字只是为了了解我们正在谈论的规模。 最多40个PBLS，每个包含数百个对象。大约500MB的代码。 大约有100名顾问在路上，其中任何人都可能 进行基础更改，然后将其转交给代码所有者。

因此，在阅读和评估各种选项后，我真的 对分布式版本控制系统感到兴奋我甚至更多 当我发现实际上有一个代理GITSCC时，很兴奋 PushOk让Powerbuilder与GIT合作。当我试着用它时 一个小小的应用程序，我很惊喜它的工作和 除了一些怪癖外，工作得相对较好。然而是什么 有趣/令人不安的是我在网上找不到一个帖子 任何人都在谈论使用GITSCC和Powerbuilder。即便是 PushOK的GITSCC论坛只有一个帖子（非Powerbuilder特定） 直到我创造了两个。 但是，一旦我使用GITSCC将我们的主要应用程序置于GIT下，我 注意到更新PBL状态的主要性能问题。

现在有几个问题，我希望有人可以帮助我：

1. 是否有人在Powerbuilder上成功使用GIT。如果 那么，你的工作流程是什么？

2. 当我刷新PBL状态时，我注意到有两个 操作非常耗时：

   • 日志将显示“正在检索的扩展状态信息” 档案：。这是在a处执行一个对象 每个物体的时间大约需要1秒钟。你可以想象我们是 如果我们刷新成千上万的物品，那就谈论几个小时

   • 偶尔，我会得到类似的行为，但是会有消息 “表演差异”。同样的事情 - 每个物体大约一秒钟。需要 永远。在工作区属性的源代码管理选项卡上，我这样做 已关闭“执行差异状态更新”。 我不是每次都得到这种行为，我点击PBL，但一旦它 开始这样做，你最好准备好长时间的午餐。 任何方法来避免/改善这种行为。这将是一个节目塞子 就像我喜欢GIT一样。我看到有些人遇到过类似的问题 其他源控制系统，所以我认为它是其中之一 与Powerbuilder或代理有关。我可以在pb.ini调整的任何内容 或其他地方改善表现？

3. 有没有人使用其他分布式版本控制系统？ 有没有办法让Mercurial与PB合作？我找不到任何东西 代理它。

4. 最后，你认为还有另一个系统吗？ 我们的工作流程？

我尝试从PushOK获得一些答案，但到目前为止他们的支持一直没有反应。我也尝试过Powerbuilder的源代码控制论坛，但是在那个小组中成员很少，我希望在SO上有更好的运气。

非常感谢任何帮助！

Answer 1

  

最后，您认为还有另一个系统可以与我们的工作流程配合使用吗？

如果您准备使用Subversion，那么Agent SVN是一个集成了PowerBuilder和Subversion的MS-SCCI插件。

以下a link介绍了它的工作原理。

Answer 2

Powerbuilder因重新排列导出的源文件中的代码而臭名昭着。这与其他人在DVCS中的变化合并不太合适。自动合并很有可能破坏PowerBuilder导出文件。使用常规diff工具手动合并是繁琐且容易出错的。我所知道的唯一可以正确合并PB Classic文件的工具是ProDiff（nee PBDelta）。到目前为止，我还没有想到使用带有PowerBuilder Classic的DVCS的工作流程，这个工作流程并不比你现在所做的更痛苦。

Answer 3

我使用Git来管理这么多不同的技术和文档。你应该没有问题。

确保人们经常推动并经常抓取。这将确保对象经常分发，因此当您想要进行激烈的操作时，您不必先等待巨大的提取完成。

坚持Mercurial的Git。这可能被视为一种观点，但我不相信那里的任何东西会比git给你更多的灵活性和选择。

我强烈建议您跳上#git irc频道。那里总是有很多乐于助人的人。

希望这有帮助。

Answer 4

我正在寻找的是Github上的从TFS到Git桥的应用程序（在所有地方），并且希望将其分叉并使其可用于VSS。据我了解，PowerBuilder中的情况是相同的，但是通过桥梁可以使事情在Git中发生，但请不要引用我。

我认为VSS与TFS类似，除了它们每天都会使企业每天损失数百万美元（合计）的生产力损失或数据库损坏。如果有人觉得我说的很夸张，那么我很容易受到批评，没有专家。