用户分散器向导
用户分散器向导
总览
分散器是一个资源库浏览器，允许你探索在Git或SVN资源库里的源代码，类似于软件Trac和GitWeb。
分散器提供了一个非常高效的SVN浏览器，一个相对高效的Git浏览器和相对缓慢的Mercurial浏览器。它通过反规范化大量的资源库历史数据到数据库中并且使用如缓存的信息来获得高效性，因此它能避免直接地查询资源库。这些数据通过守护进程生成，该进程可以追踪资源库，发现新提交，解析并导入这些数据。
在Phabricator套件中，分散器被整合进了其他的工具中。例如：
- 当你提交不同的版本到一个被追踪的资源库时，他们将自动被更新并链接到相应的提交上；
- 你可以添加预示规则以通知你关于那些匹配某些规则的提交；
- Owners工具使用分散器来映射资源库；
- 在所有的工具中，提交名称将被自动链接。
资源库呼号和提交名称
每一个资源库都使用一个简短的大写字符串，如"P" ( Phabricator) 或"ARC" ( Arcanist)这样的“呼号”来定义。
每一个资源库必须有一个唯一的呼号。呼号在已安装中必须是唯一的，但不必是全局唯一，因此，简短起见，你可以自由的使用单字母呼号。例如，Facebook使用E为Engineering资源库，O为Ops资源库，Y为Yum包管理资源库，等等，当然，Phabricator使用P，ARC，PHU为libphutil，J为Javelin。保持呼号简洁将使得他们更加易用，推荐使用单字母呼号，因为你不可能有超过26个被追踪的资源库。
呼号的主要目的是命名提交到SVN资源库的名称空间：如果你使用多个SVN资源库，每一个资源库有一个版本1，版本2等，因此仅通过数字指向到他们将会变得混淆。然而，即使Git发送给人类可读的额外信息，并允许解析器检测提交的东西使用的是高可用的名称。
Diffusion uses this callsign and information about the commit itself to generate a commit name, like "rE12345" or "rP28146171ce1278f2375e3646a1e1ea3fd56fc5a3". The "r" stands for "revision". It is followed by the repository callsign, and then a VCS-specific commit identifier (for SVN, the commit number; for Git and Mercurial, the commit hash). When writing the name of a Git commit you may abbreviate the hash, but note that hash collisions are probable for short prefix lengths. See this post on the LKML for a historical explanation of Git's occasional internal use of 7-character hashes:
https://lkml.org/lkml/2010/10/28/287
Because 7-character hashes are likely to collide for even moderately large repositories, Diffusion generally uses either a 16-character prefix (which makes collisions very unlikely) or the full 40-character hash (which makes collisions astronomically unlikely).
添加资源库
可通过"Repository"工具来完成资源库管理工作，该工具主要是一系列的分散器管理接口。添加一个资源库到分散器，你需要做：
- 在Repository工具中创建一个新的资源库；
- 开启守护进程以追踪和导入资源库。
创建一个新的资源库（编辑或删除一个一个已经存在的资源库），你需要一个管理员帐号（查看配置帐号和注册指引以修改一个已经存在的帐号为管理员帐号）。当你为管理员时，进入Repository工具栏，你将拥有创建和编辑资源库的选项。
当你创建一个新的资源库时，你需要指定一个人可读的名称，一个常量呼号（参考上一段），一个相应的VCS类型。一旦你创建成功，你可以进入Tracking标签以设置分散器追踪选项。
Tracking标签页中大部分选项都是不言自明的，保留的默认值是安全的。特别说明的是，分散器追踪SVN资源库通过定期发起“svn log”命令到远程以查找新提交。它追踪Git和Mercurial资源库通过复制一个本地版本，并定期发起git fetch或hg pull命令。
一旦你配置好一切（确保Tracking设置为启用），你可以启动守护进程开始真正追踪资源库。
运行分散器守护进程
大多数情况下，执行如下命令既可运行进程：
phabricator/bin/ $ ./phd start
如想获取关于phd和守护进程更深入的描述，请查看使用phd管理守护进程
你可以使用守护进程控制台来监视多个守护进程并查看他们导入资源库的进度。小型的资源库导入操作非常快，然而大型的资源库将消耗一些时间（在Facebook的35万个提交到主资源库的操作，开始检测提交消耗大约10分钟，导入它们大约花费了18个小时，在具有先进硬件的64个任务管理器上）。除了大型资源库外，提交内容一般几分钟后出现在分散器中。
调整守护进程
默认情况下，Phabricator启动一个守护进程来拉取和检测所有被追踪的资源库。对一些小型资源库或大多数相对不活跃的资源库，但可能在某些情况下，调整守护进程效果将变得更好。守护进程保持在资源库中配置的拉取频率以做出粗略的回应，但不能快速的导入新提交如果你有一个大型的资源库（从其他资源库进行I/O操作时将被阻塞）。
If you want to provide lower commit import latency for some repositories, you can either launch more daemons (which will generally lower latency for all repositories) or launch additional dedicated daemons (which will give you very fine-grained control over import latency).
更多守护进程
The coarse approach to reducing import latency is to simply launch more daemons, using phd:
phabricator/bin $ ./phd launch RepositoryPullLocal
This will launch another copy of the daemon. The daemons acquire a global lock before pulling a repository, so you can launch additional daemons without causing contention or race conditions.
专用的守护进程
You can take a more fine-grained approach and launch dedicated daemons for specific repositories or groups of repositories. For example, if you want low latency on the repositories with callsigns A and B, but don't care about latency for the other repositories, you could launch two daemons like this:
phabricator/bin $ ./phd launch RepositoryPullLocal -- A B phabricator/bin $ ./phd launch RepositoryPullLocal -- --not A --not B
The first one will work only on A and B, and should be able to import commits with low latency more reliably. The second one will work on all other repositories.
下一步
- 学习如何创建一个符号索引， Diffusion User Guide: Symbol Indexes
- 在细节处理解守护进程，Managing Daemons with phd
- 发送反馈给我们，Give Feedback! Get Support!