带有 GIT 的大型传统 Powerbuilder 还是?

发布于 2024-11-14 16:12:51 字数 1498 浏览 4 评论 0原文

我正在评估我们的遗留版本的各种版本/源代码控制选项 Powerbuilder 应用程序(现在在 PB11 中,将迁移到旧版 12 很快)。到目前为止,所有版本控制的来源都非常有限 控制已在内部完成,可以通过以下方式更改代码 许多旅行顾问,但变化往往是被推入 某些模块代码所有者的基础。这个工作流程对于 虽然当公司很小的时候,但随着我们的成长,它变得越来越大 更具挑战性。这是一个非常大的应用程序。我会给你 数字只是为了了解我们正在讨论的规模。 多达 40 个 PBLS,每个 PBLS 包含数百个对象。大约 500MB 的代码。 大约100名顾问不断在路上,他们中的任何一个都可能是 进行基础更改,然后将其移交给代码所有者。

因此,在阅读并评估了各种选项之后,我真的很喜欢 对分布式版本控制系统感到兴奋。我更是 当我发现实际上有一个代理 GITSCC 时,我很兴奋,由 PushOk 让 Powerbuilder 与 GIT 一起使用。当我尝试使用时 一个小应用程序,我很惊喜地发现它有效并且 除了一些怪癖之外,效果相对较好。然而什么是 有趣/令人不安的是我在网上找不到任何帖子 有人谈论将 GITSCC 与 Powerbuilder 结合使用。甚至连 PushOK 的 GITSCC 论坛只有一篇帖子(非 Powerbuilder 特定) 直到我又创建了两个。 然而,一旦我使用 GITSCC 将我们的主应用程序放在 GIT 下,我 注意到更新 PBL 状态的主要性能问题。

现在有几个问题,我希望有人能帮助我:

  1. 是否有人成功地将 GIT 与 Powerbuilder 结合使用。如果 那么,您的工作流程是怎样的?

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

    • 日志将显示“正在检索扩展状态信息” 文件: .这是在一个对象上执行的 每个对象花费大约 1 秒的时间。正如您所想象的那样 如果我们要刷新数千个对象,那么就需要几个小时。

    • 偶尔,我会得到类似的行为,但带有消息 “执行差异”。同样的事情 - 每个对象大约一秒钟。需要 永远。在工作区属性的源代码管理选项卡上,我这样做 已关闭“对状态更新执行差异”。 我并不是每次点击 PBL 时都会出现这种行为,但一旦它 开始做这件事后,你最好准备好吃一顿丰盛的午餐。 任何避免/改善这种行为的方法。这将是一个精彩的表演 就像我喜欢 GIT 一样。我看到有些人有类似的问题 其他源代码控制系统,所以我认为它要么是 与 Powerbuilder 或代理有关。我可以在 pb.ini 中调整的任何内容 或者其他地方可以提高性能?

  3. 有人使用其他分布式版本控制系统吗? 有没有办法让 Mercurial 与 PB 一起工作?我找不到任何 它的代理。

  4. 最后,是否还有其他您认为效果良好的系统 与我们的工作流程?

我尝试从 PushOK 获得一些答案,但到目前为止他们的支持没有回应。我还尝试了 Powerbuilder 源代码控制论坛,但该组中的成员很少,我希望在 SO 上有更好的运气。

非常感谢任何帮助!

I am evaluating various version/source control options for our legacy
Powerbuilder application (in PB11 now, will be migrating to legacy 12
soon). To this point, all the version control with very limited source
control has been done in-house where the code can be changed by
numerous traveling consultants, but the changes tend to be pushed into
the base by certain module code owners. This workflow was okay for a
while when the company was small, but as we grew, it became more and
more challenging. It is a very large application. I'll give you the
numbers just to get an idea of the scale we are talking about.
Up to 40 PBLS with hundreds of objects in each. About 500MB of code.
About 100 consultants constantly on the road, any of them may be
making base changes, which are then turned over to code owners.

So after reading about and evaluating various options, I was really
excited about Distributed Version Control Systems. I was even more
excited when I found that there is actually a proxy GITSCC, made by
PushOk to get Powerbuilder to work with GIT. When I tried it out with
a small application, I was pleasantly surprised that it worked and
worked relatively well, except for some quirks. However what was
interesting/disturbing is that I can't find a single post on the net
of anybody talking about using GITSCC with Powerbuilder. Even the
PushOK's GITSCC forum had only one post (non-Powerbuilder specific)
until I created two more.
However, once I put our main application under GIT using GITSCC, I
noticed major performance issues updating PBL statuses.

So now a couple of questions, which I hope someone can help me with:

  1. Is there anybody who successfully uses GIT with Powerbuilder. If
    so, what's your workflow?

  2. When I refresh PBL statuses I noticed that there are two
    operations, which are very time consuming:

    • The log will say "Retrieving extended status information for the
      files: . This is performed one object at a
      time with each object taking about 1 second. As you can imagine we are
      talking about hours if we are refreshing thousands of objects.

    • Occasionally, I will get the similar behavior, but with the message
      "performing diff". Same thing - about a second per objects. Takes
      forever. On the source control tab of the workspace properties, I do
      have "perform diff on status update" turned off.
      I do not get this behavior every time, I click on a PBL, but once it
      starts doing it, you better be ready for a long lunch.
      Any way to avoid/improve this behavior. This will be a show stopper as
      much as I loved GIT. I saw some people having similar problems with
      other source control systems, so I am thinking it's either something
      to do with Powerbuilder or the proxy. Anything I can tweak in pb.ini
      or other places to improve the performance?

  3. Is there anybody who uses other distributed version control systems?
    Is there a way to get Mercurial to work with PB? I couldn't find any
    proxies for it.

  4. Finally, is there another system which you think would work well
    with our workflow?

I tried getting some answers from PushOK, but so far their support has been unresponsive. I also tried the Powerbuilder source control forum, but with so few members in that group, I am hoping to have better luck on SO.

Any help is greatly appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

夜吻♂芭芘 2024-11-21 16:12:51

最后,您认为还有其他系统可以很好地配合我们的工作流程吗?

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

这里的链接描述了它的工作原理。

Finally, is there another system which you think would work well with our workflow?

If you are prepared to look into using Subversion, then Agent SVN is a MS-SCCI plug-in that integrates PowerBuilder and Subversion.

Here is a link describes how it works.

萌化 2024-11-21 16:12:51

Powerbuilder 因重新排列导出的源文件中的代码而臭名昭著。这对于在 DVCS 中合并其他人的更改来说效果不佳。自动合并很可能会损坏 PowerBuilder 导出文件。使用常规比较工具进行手动合并既乏味又容易出错。据我所知,唯一可以正确合并 PB Classic 文件的工具是 ProDiff(nee PBDelta)。到目前为止,我还没有想到使用 DVCS 和 PowerBuilder Classic 的工作流程不会比您现在所做的更痛苦。

Powerbuilder is notorious for rearranging code in the exported source files. This does not play well with merging in other people's changes in a DVCS. An automated merge has a good chance of corrupting a PowerBuilder export file. Merging by hand is tedious and error-prone with regular diff tools. The only tool I know of that can correctly merge PB Classic files is ProDiff (nee PBDelta). So far I haven't been able to think of a workflow using a DVCS with PowerBuilder Classic that isn't more painful than what your're doing now.

ペ泪落弦音 2024-11-21 16:12:51

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

确保人们经常推送和提取。这将确保对象频繁分发,因此当您想要执行密集操作时,您不必首先等待巨大的获取完成。

坚持使用 Git 而不是 Mercurial。这可能被视为一种意见,但我不相信任何东西都会给你比 git 更多的灵活性和选择。

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

希望这有帮助。

I have used Git to manage so many different technologies and documents. You should have no issues.

Ensure that people are pushing often and fetching often. This will make sure that objects are distributed frequently so when you want to do an intense operation, you won't first have to wait for a gigantic fetch to finish.

Stick with Git over Mercurial. This may be seen as an opinion but I'm not convinced that anything out there will give you more flexibility and options than git.

I would highly recommend jumping in on the #git irc channel as well. There's lots of helpful people there always.

Hope this helps.

倾`听者〃 2024-11-21 16:12:51

我正在查看的是(所有地方)Github 上的TFS 到 Git 桥应用程序,并希望分叉它并使其适用于 VSS。据我了解,PowerBuilder 中的情况是相同的,但是桥梁使 Git 中的事情发生,但不要引用我的话。

我认为 VSS 与 TFS 类似,除了它们都因生产力损失或数据库损坏而每天给公司造成数百万美元(合计)的损失。如果有人觉得我所说的有些夸张,我愿意接受批评,而不是专家。

What I'm looking at is a TFS to Git bridge application on Github (of all places) and want to fork it and make it work for VSS. From what I understand things are the same in PowerBuilder, but the bridge makes things happen in Git, but don't quote me.

I am thinking VSS is similar to TFS, besides the fact they both cost corporations millions of dollars a day (combined) in lost productivity, or corrupt databases. If anyone feels what I've said is an exaggeration, I'm open to criticism, no expert.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文