"责备"命令的简化语义是一件好事吗？

Question

我正在研究一种新的基于编织的数据结构,用于存储版本控制历史记录.这无疑会引发一些宗教战争,当它出现时是否是正确的做事方式,但现在这不是我的问题.

我的问题与输出责任应该给予什么有关.当一行代码被添加,删除并多次合并到自身时,并不总是清楚哪些修订应该归咎于它.值得注意的是,这意味着当一段代码被删除时,它的所有记录都已消失,并且没有责任去除.我已经解决过这个问题的每个人都说过,努力做得更好根本就不值得.有时候人们会把删除部分之后的行更改为从删除部分时的实际修改版本.据推测,如果该部分在最后,那么最后一行就会改变它的责任,如果文件结束为空,那么责任确实会消失在以太中,因为实际上没有任何地方可以归咎于责备信息.由于各种技术原因,我不会使用这个hack,但是假设继续但是这个完全没有文档但事实上的标准实践将是无可争议的(但是随意点燃我并将其从你的系统中取出).

继续我的实际问题.通常对每一行都负责,你会看到它在历史中添加和删除的完整历史记录,并使用三向合并(或者,在纵横交错合并的情况下,随机废话)并基于这些之间的关系您根据其历史记录确定该行是否应该在那里,如果它不应该,那么您使用当前版本将其标记为新的.如果一条线出现在具有不同blame的多个祖先中,那么它会选择哪一个任意继承.同样,我认为继续这种完全无证但事实上的标准做法将是无可争议的.

我的新系统分歧的地方在于,不是根据整个历史的复杂计算对一个给定的行是否应该在当前修订中进行复杂的计算,而是简单地查看直接的祖先,如果该行是在任何一个他们选择任意一个继承责任.我在很大程度上是出于技术原因而做出这种改变(并且由于类似的技术原因和缺乏关心,完全有可能其他责任实现做同样的事情)但在考虑之后,我的一部分实际上更喜欢新的行为.比旧的更直观和可预测.每个人都在想什么？

Answer 1

I actually wrote a one of the blame implementations out there (Subversion's current one I believe, unless someone replaced it in the past year or two). I helped with some others as well.

At least most implementations of blame don't do what you describe:

Usually in blame for each line you look at the complete history of where it was added and removed in the history and using three way merge (or, in the case of criss-cross merges, random bullshit) and based on the relationships between those you determine whether the line should have been there based on its history, and if it shouldn't but is then you mark it as new with the current revision. In the case where a line occurs in multiple ancestors with different blames then it picks which one to inherit arbitrarily. Again, I assume that continuing with this completely undocumented but de facto standard practice will be uncontroversial.

Actually, most blames are significantly less complex than this and don't bother trying to use the relationships at all, but they just walk parents in some arbitrary order, using simple delta structures (usually the same internal structure whatever diff algorithm they have uses before it turns it into textual output) to see if the chunk changed, and if so, blame it, and mark that line as done.

For example, Mercurial just does an iterative depth first search until all lines are blamed. It doesn't try to take into account whether the relationships make it unlikely it blamed the right one.

Git does do something a bit more complicated, but still, not quite like you describe.

Subversion does what Mercurial does, but the history graph is very simple, so it's even easier.

In turn, what you are suggesting is, in fact, what all of them really do:

Pick an arbitrary ancestor and follow that path down the rabbit hole until it's done, and if it doesn't cause you to have blamed all the lines, arbitrarily pick the next ancestor, continue until all blame is assigned.

Answer 2

在个人层面上,我更喜欢你的简化选项.

原因:无论如何都不会使用责备.

因此,我没有看到浪费大量时间进行全面实施的重点.

这是真的.Blame在很大程度上被证明是"彩虹尽头的金罐"之一.我们这些站在地上的人看起来真的很酷,梦见有一天我们可以点击一个文件,看看谁写了哪行代码.但是现在它被广泛实施,我们大多数人已经意识到它实际上并没有很大帮助.blame在Stack Overflow 上检查标签上的活动.这是荒凉的荒凉.

仅在最近几个月我就遇到过几十个"非常值得责备"的情景,在大多数情况下,我试图首先使用责备,并发现它既麻烦又完全无益.相反,我通过对相关文件执行简单的过滤更改日志来找到我需要的信息.在某些情况下,我本可以使用Blame找到信息,如果我坚持不懈,但这需要更长的时间.

主要问题是代码格式更改.几乎所有事情的第一层责任都被列为......我!为什么？因为我是负责修复换行符和标签的人,重新排序功能顺序,将功能拆分为单独的实用程序模块,修复注释拼写错误,以及改进或简化代码流.如果不是我,那么其他人也做了一个空白或阻止移动到某个地方.为了得到一个有意义的责备,在我没有责备的帮助之前可以记得的时间之前,我不得不回滚修改和重新责备.并再次责怪.然后再次.

因此,为了让责任实际上比最幸运的情况更有用的节省时间,责任必须能够启发式地超越换行符,空格,并且理想地阻止复制/移动更改.这听起来像一个非常高的订单,特别是在搜索单个文件的更改日志时,大多数时候,它不会产生很多差异,你可以很快地手工筛选.(值得注意的例外是,可能是设计糟糕的源代码树,其中90%的代码被填充在一个或两个巨大的文件中......但是现在谁在协作编码环境中做了大量的事情呢？).

结论:给它一个简单的责任实施,因为有些人喜欢看"它可以怪!" 在功能列表上.然后继续讨论重要的事情.请享用!