为什么一个SVN分支在commit后跳出100个修订版本差异? [英] Why does a SVN branch jump with 100 revisions difference after commit?

查看:62
本文介绍了为什么一个SVN分支在commit后跳出100个修订版本差异?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚提交了与修订版 448 相关的本地更改.之后我注意到修订版 549,那么现在有什么问题.... 任何想法(这不是什么大不了的事,但我无法解释它让我徘徊......)?

我确实记得创建了一个分支,我猜这应该是问题所在,但有点奇怪.

解决方案

Deyan, Alvaro 差点碰到问题的根源,但我会详细说明.我不知道 GitHub 的 SVN-bridge 的所有内部结构,但是你的 repo 暴露的 SVN 端似乎(对于纯 SVN 人)是被骗的",因为

  • SVN 历史是线性的
  • 较大的修订 ID 必须表示提交的较晚日期"
  • Revision-id 是自动递增计数器

但是

  • svn log in range 482:483 似乎很奇怪
<块引用>

r484 |deyan.dobromirov |2015-08-10 10:07:54 +0500 (Пн, 10 авг 2015)-----------------------------------------------------------------r483 |deyan.dobromirov |2015-08-10 10:05:34 +0500 (Пн, 10 авг 2015)-----------------------------------------------------------------r482 |deyan.dobromirov |2015-09-01 13:55:03 +0500 (Вт, 01 сен 2015)

(注意 483+ 修订的日期之前 482)

  • 通过快速搜索,我发现了一些缺失"的修订
<块引用>

r552 |deyan.dobromirov |2015-09-01 18:36:55 +0500 (Вт, 01 сен 2015)-----------------------------------------------------------------r550 |deyan.dobromirov |2015-09-01 17:49:52 +0500 (Вт, 01 сен 2015)-----------------------------------------------------------------r548 |deyan.dobromirov |2015-09-01 17:49:52 +0500 (Вт, 01 сен 2015)

...

r186 |deyan.dobromirov |2015-01-28 14:35:30 +0500 (Ср, 28 янв 2015)-----------------------------------------------------------------r184 |deyan.dobromirov |2015-01-28 12:23:56 +0500 (Ср, 28 янв 2015)-----------------------------------------------------------------

  • Github 在单个分支 master 中声明284 次提交",但 SVN 认为
<块引用>

>svn log -q -r HEAD-----------------------------------------------------------------r554 |deyan.dobromirov |2015-09-01 19:08:39 +0500(2015 年 1 月 1 日)-----------------------------------------------------------------

关于精神错乱的权利:554 是 284*2,没有 14 次丢失提交

附加说明:当我使用 Mercurial 克隆您的存储库时(Hg 可以同时克隆 Git 和 SVN 存储库),对于 Git 源,我收到了 284 次提交,正如预期的那样,对于我正在等待的 SVN 源(在此过程中,它是长程序)与 SVN 客户端相同的结果,带有 SVN-URL: 554

<小时>

中级初步诊断

您的存储库的 SVN 接口几乎没有损坏,您必须将此问题通知 GitHub 技术支持并寻求帮助

进一步探索

对于好"的 GitHub 存储库,从 Git 和 SVN URL 克隆必须提供相同的结果(相同的存储库),但是您的 SVN 存储库非常脏:很多分支(Git 不知道)

lol 543:f585d0a8ee89(已关闭)LuaDB 541:816e1f7df77f(已关闭)TimerOsClock 344:a4bf94c50012(关闭)Timer-os.clock() 343:27e5c55368d8(关闭)变量空间 316:69a4aa153a0c(关闭)GhostAllProps 313:13352bdb9fb0(已关闭)CashePoolTest 183:a90989b79d70(已关闭)

对这些幽灵分支的大量重复提交(屏幕截图上的 1、2、3)、非线性历史(对于 SVN 来说完全不可能):请参阅(仅部分)子项以了解 r401(用黑圈标记)

最终建议

不要盲目地将 Github 用于 SVN 项目,其中有很多 SVN 风格的分支,它的桥梁变得疯狂和不可预测.Github 适用于线性 SVN 开发,最后但并非最不重要的是,SVN 访问是幕后真实 Git 存储库的最后手段",还没有准备好应对任何困难的用例

I just made a commit with my local changes related to revision 448. After that I noticed revision 549, So what's wrong now .... Any Ideas ( Not that is a big of a deal, but I can't explain it and make me wander ...) ?

I did remember making a branch though, that should be the problem I guess but it's kinda strange.

解决方案

Deyan, Alvaro almost hit source of problem, but I'll show it in details. I don't know all internals of GitHub's SVN-bridge, but exposed SVN-side of your repo seems (for pure SVN man) as "cheated", because

  • SVN history is linear
  • Bigger revision-id must mean "later date of commit"
  • Revision-id is autoincrement counter

but

  • svn log in range 482:483 seems, well, strange

r484 | deyan.dobromirov | 2015-08-10 10:07:54 +0500 (Пн, 10 авг 2015)
------------------------------------------------------------------------
r483 | deyan.dobromirov | 2015-08-10 10:05:34 +0500 (Пн, 10 авг 2015)
------------------------------------------------------------------------
r482 | deyan.dobromirov | 2015-09-01 13:55:03 +0500 (Вт, 01 сен 2015)

(note dates of 483+ revision before 482)

  • with fast eye-search I see some "missing" revisions

r552 | deyan.dobromirov | 2015-09-01 18:36:55 +0500 (Вт, 01 сен 2015)
------------------------------------------------------------------------
r550 | deyan.dobromirov | 2015-09-01 17:49:52 +0500 (Вт, 01 сен 2015)
------------------------------------------------------------------------
r548 | deyan.dobromirov | 2015-09-01 17:49:52 +0500 (Вт, 01 сен 2015)

...

r186 | deyan.dobromirov | 2015-01-28 14:35:30 +0500 (Ср, 28 янв 2015)
------------------------------------------------------------------------
r184 | deyan.dobromirov | 2015-01-28 12:23:56 +0500 (Ср, 28 янв 2015)
------------------------------------------------------------------------

  • Github states "284 commits" in single branch master, but SVN think

>svn log -q -r HEAD
------------------------------------------------------------------------
r554 | deyan.dobromirov | 2015-09-01 19:08:39 +0500 (Вт, 01 сен 2015)
------------------------------------------------------------------------

On the rights of delirium: 554 is 284*2 without 14 somehow lost commits

Additional notes: when I cloned your repo with Mercurial (Hg can clone both Git and SVN repos), for Git-source I got 284 commits, as expected, for SVN-source I'm awaiting (in the process, it's long procedure) the same result as it was for SVN-client with SVN-URL: 554


Intermediate preliminary diagnosis

SVN-interface to your repo is hardly broken, you have to inform GitHub tech-support about this issue and ask for help

Further explorations

For "good" GitHub repository, cloning from Git and SVN URLs must provide the same results (the same repos), but your SVN-repo is extremely dirty: a lot of branches (unknown to Git)

lol                          543:f585d0a8ee89 (closed)
LuaDB                        541:816e1f7df77f (closed)
TimerOsClock                 344:a4bf94c50012 (closed)
Timer-os.clock()             343:27e5c55368d8 (closed)
VariableSpace                316:69a4aa153a0c (closed)
GhostAllProps                313:13352bdb9fb0 (closed)
CashePoolTest                183:a90989b79d70 (closed)

a lot of duplicated commit to these ghostly branches (1, 2, 3 on screenshot), non-linear history (totally impossible for SVN): see (only part of) children for r401 (marked with black circles)

Final recommendations

Don't use Github for SVN-projects with a lot of branching in SVN-style blindly, it's bridge become crazy and unpredictable. Github is good for linear SVN-development and, at last but not least, SVN-access is "tool of last resort" for real Git repositories behind the scene, not ready for any hard use-cases

这篇关于为什么一个SVN分支在commit后跳出100个修订版本差异?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆