svn专家的简单问题:
现在我正在做一个大项目的第一次提交(不需要解释细节),它就像几乎2 Gb的文件。
承诺花了很长时间,我看到点像往常一样向前移动。所以我的问题是,是否有办法显示我的提交的详细进度,因为我不知道真正的进展,已经上传了多少,以及有多少未决。
由于
答案 0 :(得分:10)
目前无法通过命令行客户端查看更多详细信息,但您可以通过发送电子邮件向users@subversion.apache.org发送电子邮件来询问。我们实际上有信息来打印更多数据(传输速度和完成百分比可能很棘手,但我们至少可以提供正在传输的文件)。如果您不愿意等待Subversion本身,您可以修改客户端以打印您想要的任何内容,通知功能并不是非常复杂。
不幸的是,David W.的回答并不准确。在服务器尝试执行提交并且数据已经在服务器上时显示句点的印象是完全错误的。这些时段显示为文件内容的每个文本增量(在某些情况下可能是全文)开始传输(正如在句点开始之前打印的“传输文件数据”所暗示的那样)。因此,第一个文本发送时将显示第一个句点,完成后将显示第二个句点,第二个文本即将开始,依此类推。因此,如果你知道你提交了多少文件,你可以从这个输出中了解它的距离。
超级技术内部细节如下。输出在svn_client_ctx_t中设置的通知回调函数中实现(ctx是上下文的缩写)。对于提交,您可以看到从subversion/libsvn_client/commit_util.c中实现的svn_client__do_commit函数调用此函数,如下所示:
if (ctx->notify_func2)
{
svn_wc_notify_t *notify;
notify = svn_wc_create_notify(item->path,
svn_wc_notify_commit_postfix_txdelta,
iterpool);
notify->kind = svn_node_file;
notify->path_prefix = notify_path_prefix;
ctx->notify_func2(ctx->notify_baton2, notify, iterpool);
}
该代码发送的事件是svn_wc_notify_commit_postfix_txdelta,如果您查看该代码的上下文,就会在为路径传输文本增量之前发送该代码。
在这里,大卫在上面的回答中有一小部分真理。树点增量已经通过此点传输(这意味着已经发送了复制,删除,mkdir等)。但是,正如事件和代码上下文所暗示的那样,文本增量会在所有内容完成后被延迟发送。正如David所指出的那样,这并没有特别有助于避免长时间失败,因为它们已经过时了,但最终即使我们优化了在delta编辑器驱动期间发生的失败,我们仍然需要检查尝试将事务(正在构建编辑驱动器时)转换为任何过时情况的修订版,因为我们不会在事务期间锁定存储库(这有助于防止Subversion在大量人们正在承诺)。我相信我们实际上已经试图让服务器更快地返回错误,但我最近没有在该代码中挖掘,所以我不打算尝试对此做出明确的陈述。
在接收到所有数据后实际处理事务所花费的时间相对较少(因为我们必须在此处理过程中取出对repo的写锁定)。 Subversion提交速度有两大漏洞。在DAV(http / https)的情况下,增量驱动器的大多数步骤发生在单独的HTTP请求中(根据DAV和DeltaV标准的设计)。这些请求是串行执行的,导致往返延迟。这包括发送文件内容。当对DAV进行大量小改动时,这极大地促成了延迟。如果这是您的常见情况,则可以使用svnserve而不是DAV来避免此问题。在未来,我们希望通过流水线来帮助减轻这些问题。第二个问题是我们不能并行发送多个文件的文本增量。这会影响所有各种网络协议,并且当前无法实现,因为事务的文件系统实现不支持它。我们希望将来能够解决这个问题,将DAV从霓虹灯切换到农奴是向前迈出的一步,因为农奴在这方面有更多的能力。
返回通知情况。命令行客户端的通知回调函数在subversion/svn/notify.c中在名为notify()的函数中实现。如果您搜索svn_wc_notify_commit_postfix_txdelta,您会找到以下代码:
case svn_wc_notify_commit_postfix_txdelta:
if (! nb->sent_first_txdelta)
{
nb->sent_first_txdelta = TRUE;
if ((err = svn_cmdline_printf(pool,
_("Transmitting file data "))))
goto print_error;
}
if ((err = svn_cmdline_printf(pool, ".")))
goto print_error;
break;
这是您的期间打印的地方。该函数的n参数是svn_wc_notify_t,它具有提供信息的各种字段。在这种情况下,应该设置path,action,kind和path_prefix。因此,应该可以通过一些简单的修改轻松显示正在传输的文件名。
答案 1 :(得分:2)
答案简短:不,你看不到细节。在您看到期间时,您的Subversion客户端已将您的更改传递到Subversion服务器。现在,服务器正在尝试查看它是否可以提交这些更改。此时,一切都在服务器上,服务器和客户端之间的通信是有限的。
您的Subversion客户端就像20世纪60年代期待情景喜剧的父亲一样。在它结束之前,没有人会告诉他一件该死的东西。他只是在候诊室里上下踱步,抽烟,直到有人告诉他最终结果。
您的Subversion客户端已将更改传递给Subversion服务器。当你看到句点时,你的Subversion客户端来回踱步,直到它听到来自Subversion服务器的单词发生的事情(恭喜!这是一个提交!)。
现在,一个大问题:你在做什么,提交2千兆字节的文件?如果您提交的大量文件中有一个文件无法提交,则您的整个提交将被拒绝。所有这些等待浪费。
svn add
并提交更改。这会让您丢失分支上的整个历史记录并阻止合并和差异化,因为就Subversion而言,分支上的文件与 trunk上的文件完全不同。您失去了分支机构的全部目的,这有助于您了解它与主干的区别。此外,由于Subversion必须在您的存档中再次添加整个项目,因此需要很长很长时间
svn cp
。更好的是,使用URL格式执行此操作,而不是复制到工作目录中。那是svn cp --parents http://server/trunk/project http://server/branch/1.2/project
。这样可以保持您的历史记录不变,Subversion几乎可以立即创建分支。到目前为止,您的提交可能已完成。你或者被告知你的提交已经发生,或者被拒绝了,你浪费了20到40分钟,看着那段小时间一遍又一遍地打印出来。下次,不要尝试这么大的提交。分开来。不要提交构建的工件。如果您需要构建的工件,则可以重建它。 (您也可以将它们存储在不受Subversion控制的Release Repository中的其他项目中。)
答案 2 :(得分:0)
我对此做了一点调查,我做了一个大提交(1060个文件),最后我检查了输出。我发现点的数量与文件的数量完全匹配(包括添加,删除和发送文件)。
这是在mac上完成的,但它可以在任何* nix上完成,可能在运行cygwin或类似的Windows上完成。
我测试的方式是"传输文件数据"阶段开始,将其复制/粘贴到临时文件中,然后执行wc -l your_file
,这将为您提供总文件。
然后计算进度复制点和echo "PASTE_DOTS_HERE" | wc -c
以获取到目前为止处理的文件,然后除以总文件并乘以100,这样可以大致了解进度百分比。
请注意,不同尺寸的文件需要更长的时间才能发送和处理,因此这些点不会同时显示。
希望能有所帮助。