如何为 TeamCity 集成 git 和 svn?

发布于 2024-10-28 05:55:56 字数 769 浏览 5 评论 0原文

目前:

  1. TeamCity 设置为从 SVN 构建。
  2. TeamCity 设置为从 GIT 构建。
    • 在 TC 服务器上(而不是在代理上)Git bare 存储库

我手动(从我的存储库,其中包含 svn ref)变基(git spull - 标准别名)并签入 TC 上的裸 git 存储库服务器(git 推送)。

当我们正在迁移到 git 的过程中(假设我们能弄清楚如何!),我们有来自 svn 和 git 的签入。

需要注意的一件事是,即使每个人都根据公司政策停止签入 svn 存储库,也需要更新它。 (因此在成功构建后,我们将触发“git spush”)

TeamCity 的设置是什么?

  1. 最坏的情况是我手动从 svn 中拉取(直到每个人都关闭 svn)并重新建立裸 git 存储库的基础。在每个人都迁移后,根据上述公司政策,这将继续。
  2. 另一种方法可能是将 svn 引用添加到裸存储库中,并编写一个脚本,该脚本将通过 TC 每小时左右调用“git spull”。
    • 如果存在合并冲突可能会出现问题
    • 还需要另一个配置,以便在成功构建后“git spush”
  3. 还有另一种方法,可能是使用 svn 插件来触发“svn每次签入 svn 后,将其放在一个特殊分支中,并通过手动合并步骤将其放在一个特殊分支中(比选项 1 稍好,并消除了选项 2 的最坏情况)

还有其他方法吗?有人在做类似的事情吗?

Currently:

  1. TeamCity is setup to build from SVN.
  2. TeamCity is setup to build from GIT.
    • Git bare repo on the TC server (not on agent)

I'm manually (from my repo, which has the svn ref) rebasing (git spull - standard alias) and checking in to the bare git repo on the TC server (git push).

As we're in the process of migrating to git (assuming we can figure out how!) we have checkins from both svn and git.

One thing to note is that the svn repo will need to be updated even after everyone stops checking in to it per company policy. (So after a successful build, we'll trigger a "git spush")

What would be the setup for TeamCity?

  1. Worst case scenario is that I manually pull from svn (until everyone is off svn) and rebase the bare git repo. This would continue after everyone has migrated, per company policy described above
  2. Another way might be to add the svn ref to the bare repo and write a script that will call "git spull" every hour or so via TC.
    • Could be trouble if there are merge conflicts
    • Will also need another config that will "git spush" after a successful build
  3. Yet another way, might be to have a svn plugin to trigger the "svn spull" after every checkin in svn and drop that off in a special branch with a manual merge step (slightly better than option 1 and removes the worst case for option 2)

Any other ways? Anyone doing something similar?

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

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

发布评论

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

评论(2

情魔剑神 2024-11-04 05:55:56

该死的,我希望我早点发现这个博客!

http://www.tfnico.com/presentations/git-and-subversion

我也得出了类似的结论,但浪费了5-6个小时。

Darn it, I wish I found this blog earlier!

http://www.tfnico.com/presentations/git-and-subversion

I've come to similar conclusions, but wasted 5-6 hours.

最后的乘客 2024-11-04 05:55:56

首先,我非常有兴趣了解您在迁移完成后如何完成迁移。一篇博客文章或一些写下你的经历、记录你遇到的问题的东西,将是一个很棒的资源。我正在考虑在我的工作地点开始同样的迁移。

我认为选项 2 听起来最明智,但是我不确定为什么您需要设置拉操作和推操作。为什么不继续将成功的构建推送到 SVN 以使其与 Git 保持同步呢?

First, I would be very interested to read how you accomplished your migration once it's completed. A blog post or something writing up your experiences, documenting the problems you hit, would be a fantastic resource. I'm thinking of starting the same migration at my place of work.

I think option 2 sounds most sensible, but I'm not sure why you would need to set up a pull operation as well as a push. Why not just continue with the successful builds being pushed to SVN to keep that in sync with Git?

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