中断看似挂起的 dcommit 调用是否安全?

发布于 2024-10-02 18:04:17 字数 1095 浏览 4 评论 0原文

我正在使用 git-svn 桥,并重新整理了我的存储库中的大量文件,以便它的组织得更好一些。

我运行 git svn dcommit 来将更改放回 SVN 服务器,该进程似乎已挂起。在过去 45 分钟内,dcommit 调用没有 CPU 使用情况,也没有网络使用情况。输出卡在:

> git svn dcommit
...snip...
     R       zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h
     R       zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h
     R       zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib
     R       zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb
     R       zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib
     R       zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb

并且这个位置已经持续了大约 45 分钟。

编辑:它最终结束说 HTTPS 连接超时。这大约花了一个半小时。

我似乎找不到任何关于如果我中断此 dcommit 调用会发生什么以及我需要做什么的明确信息在我尝试将更改从本地存储库重新提交回 SVN 服务器之前。

我可以回答我的问题的一部分:在再次尝试之前我需要做什么?

连接超时并返回提示后,我必须先执行 git svn fetch ,然后才能再次运行 git svn dcommit 。我所有的重命名操作都在 SVN 存储库中找到,但洗牌后留空的目录没有被删除。我必须使用我的 SVN 客户端来删除它们。我不确定这是否是 git-svn 的问题,还是因为 dcommit 调用期间 HTTPS 超时。

我仍然不知道以下问题的答案:中断 dcommit 调用安全吗?

I'm using the git-svn bridge and have reshuffled a large number of files around in my repository so it's organized a bit better.

I ran git svn dcommit to put the changes back at the SVN server and the process appears to be hung up. I'm getting no CPU use and no network use for the dcommit call for the past 45 minutes. The output is stuck at:

> git svn dcommit
...snip...
     R       zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h
     R       zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h
     R       zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib
     R       zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb
     R       zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib
     R       zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb

And that's where it's been for about 45 minutes now.

Edit: it eventually ended saying the HTTPS connection timed out. This took about an hour and a half to happen.

I can't seem to find any definitive information on what will happen if I interrupt this dcommit call and what I'd need to do before I attempt to resubmit the changes again from my local repository back to the SVN server.

I can answer one part of my question: What would I need to do before trying again?

After the connection timed out and my prompt was returned I had to do a git svn fetch before I could run git svn dcommit again. All of my rename operations were found in the SVN repository but directories that were left empty after the shuffle were not deleted. I had to use my SVN client to remove them. I'm not sure if this a git-svn thing or because of the HTTPS timeout during that dcommit call.

I still don't know the answer to: Is interrupting a dcommit call safe?

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

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

发布评论

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

评论(1

独留℉清风醉 2024-10-09 18:04:17

是的,它很安全。

dcommit 基本上对您推送到 SVN 的每个提交执行此操作:

  1. 计算提交与其父提交之间的差异。 (本质上,为提交创建补丁。)
  2. 通过 SVN 协议发送此差异作为要提交的变更集。一旦完成,提交现在就存在于 SVN 服务器上。
  3. 获取新提交以及其他用户同时创建的任何其他新提交,并将它们作为正确的 Git 提交存储在本地。 git-svn 分支引用将更新为指向最新的分支。
  4. 将刚刚处理后的所有提交重新设置为正在提交的 git-svn 分支引用。 (由于正在处理的提交现在应该存在于服务器上,这将导致刚刚处理的本地提交被丢弃,就像任何其他变基一样。)

如果您在步骤 2 期间中断(这就是听起来的样子),那么当前提交将在 svn 服务器上中止。您应该能够毫无顾虑地再次提交。

但是,如果您很偏执(在像这样的 VCS 之间互操作时应该如此),您可能需要首先运行 git svn rebase 。这将拉下 SVN 上的任何新提交(包括您尝试推送的提交,如果它实际上在服务器端成功的话),并在其之上重新建立本地分支。

Yes, it is safe.

dcommit basically does this for each commit you are pushing to SVN:

  1. Compute the difference between the commit and its parent. (Essentially, creating a patch for the commit.)
  2. Send this difference over the SVN protocol as a changeset to be committed. Once this is complete, the commit now lives on the SVN server.
  3. Fetch the new commit, and any other new commits that were created in the meantime by other users, and store them locally as proper Git commits. The git-svn branch ref will be updated to point to the latest one.
  4. Rebase all the commits after the one just processed onto the git-svn branch ref being committed to. (Since the commit being processed should now live on the server, this will result in the local commit that was just processed being discarded, as per any other rebase.)

If you interrupt during step 2 (which is what it sounds like) then the current commit will be aborted on the svn server. You should be able to dcommit again without worry.

But, if you are paranoid (and you should be when interoperating between VCSes like this) you may want to run git svn rebase first. This will pull down any new commits on SVN (including the commit that you tried to push, if it actually succeeded server-side) and rebase your local branch on top of it.

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