在它出现之前,我已经看过这个主题的几个主题,包括:
我正在寻找为我们的开发小组切换到Mercurial(来自Subversion).在我这样做之前,我正在做通常的利弊列表.
我的"优点"之一是Mercurial的合并优势,但到目前为止,我没有找到令人信服的证据.也就是说,在HgInit.com上发表声明,我无法核实:
例如,如果我稍微更改一个函数,然后将其移动到其他地方,Subversion就不会真正记住这些步骤,所以当合并的时候,它可能会认为一个新的函数只是出现了蓝色.Mercurial将分别记住这些事情:功能已更改,功能已移动,这意味着如果您稍微更改了该功能,则Mercurial更有可能成功合并我们的更改.
这将是非常引人注目的功能,但据我所知,这只是热空气.我一直无法验证上述声明.
我创建了一个Mercurial存储库,做了一个Hello World,然后克隆了它.在一个我修改了函数,提交它然后移动它,然后提交它.在另一个中,我只是在函数中添加了另一个输出行并提交了.
当我合并时,我得到的基本相同的合并冲突我将使用Subversion.
我知道mercurial可以更好地跟踪文件重命名,除了合并之外DVCS还有其他优点,但我对这个例子很感兴趣.乔尔斯波尔斯基在这里偏离基地,还是我错过了什么？
我在这方面没有经验,但看起来确实如此,因为Mercurial保留了更多的信息,理论上它可以更好地合并(如果开发人员也经常进行签名).例如,我认为Mercurial可以通过比较多个更改来获取上下文更改,例如,我修改函数,签入,移动函数,签入,以及Mercurial将这两个部分关联起来.
但是,Mercurial的合并似乎并没有真正利用添加的信息,并且似乎与Subversion的操作方式相同.它是否正确？
所以我已经实现了Android USB Accessory API,这样我就可以将手机插入运行linux的笔记本电脑,并将手机置于USB附件模式.然后我可以访问附件,打开它,然后开始阅读它.我的代码看起来几乎与文档中的示例相同.主要区别在于我使用单独的读写方法并通过本机代码通过JNI访问它们.
这是有趣的地方.成功读取/写入一两秒后,我的笔记本电脑的批量传输写入开始发出超时错误,然后对Android中的USB附件的读取调用会引发带有ENODEV错误代码的IOException.这是在电缆仍然连接的情况下,UsbManager仍在列表中列出附件,我仍然有权使用它.
为了增加它的奇特性,我发现如果我在读取循环中放置一个100ms的睡眠,问题基本上消失了(虽然它偶尔会发生).在那里睡觉不仅仅是一个可怕的kludge,但它在我的应用程序中引入了无法忍受的延迟.睡眠时间越短,黑客的有效性越低,在10ms的睡眠时间内无效.
我使用批量传输传输大约20-30kbps的实时数据(但不是实时的,批量传输是不够的),传输大小范围从50到800字节,大约20-30Hz.这可能是USB的限制吗？我没有太多的经验,所以我基本上把它当作网络套接字处理它.我是否应该将较小的消息排队并以较低频率但较大的传输将它们一起发送出去？小型,高频率的批量转移是否存在问题？我会调查一下,但我基本上都在抓稻草.
硬件: