Change Details

Long ago, Phabricator organized code primarily in terms of "Arcanist Projects". These were roughly human-readable labels for subdirectories in a repository, like "frontend-server" or "internal-tools". This was somewhat natural in large SVN repositories, where one repository often contained multiple logical projects (each with its own independent codebase and rulesets), and these were the first kind of repositories Phabricator worked with (at Facebook, circa 2007). Subversion is much less popular now than it was in 2007, and Git and Mercurial are much more popular. With Git and Mercurial, it is far more common to organize code in many different repositories, where each repository is one logical project. In this case, the concept of "arcanist projects" isn't useful, because they always map directly to repository roots but add an unnecessary layer of indirection, complexity, and confusion. To make this problem worse, "projects" have become a much more core part of the product, and many users experience significant confusion when they learn that "arcanist projects" and "projects" are entirely separate things, even though they basically have the same name. Phabricator's integration with repositories and tooling for segmenting rulesets for a codebase has improved over time, and we've reduced the importance of "arcanist projects". Circa 2011 they were mandatory; circa 2012-2013 they became optional; we are now removing them entirely. We believe they are virtually unused by modern installs and that installs with large SVN repositories now have other tools available which can serve the same purposes in almost all cases without requiring us to retain this confusing relic of a bygone era.

Long ago, Phabricator organized code primarily in terms of "Arcanist Projects". These were roughly human-readable labels for subdirectories in a repository, like "frontend-server" or "internal-tools". This was somewhat natural in large SVN repositories, where one repository often contained multiple logical projects (each with its own independent codebase and rulesets), and these were the first kind of repositories Phabricator worked with (at Facebook, circa 2007). Subversion is much less popular now than it was in 2007, and Git and Mercurial are much more popular. With Git and Mercurial, it is far more common to organize code in many different repositories, where each repository is one logical project. In this case, the concept of "arcanist projects" isn't useful, because they always map directly to repository roots but add an unnecessary layer of indirection, complexity, and confusion. To make this problem worse, "projects" have become a much more core part of the product, and many users experience significant confusion when they learn that "arcanist projects" and "projects" are entirely separate things, even though they basically have the same name. Phabricator's integration with repositories and tooling for segmenting rulesets for a codebase has improved over time, and we've reduced the importance of "arcanist projects". Circa 2011 they were mandatory; circa 2012-2013 they became optional; we are now removing them entirely. We believe they are virtually unused by modern installs and that installs with large SVN repositories now have other tools available which can serve the same purposes in almost all cases without requiring us to retain this confusing relic of a bygone era. --- FAQ ====== **What are "Arcanist Projects"? Are these the same as "Projects"?** "Arcanist Projects" are not the same as "Projects". One of the reasons we are removing arcanist projects is that they are often a source of confusion, precisely because they have such a similar name. Arcanist projects were completely separate, and configured in the very old {nav Repositories > Arcanist Projects} UI. If you use Git or Mercurial and/or started using Phabricator in the last two years, there's a good chance you've never encountered them and this change may not affect you at all. **Are you removing "Projects"?** No. Projects are a cornerstone of the product, and all our plans around them involve improving them and making them more useful. --- Updating ======= **How do I update `.arcconfig`?** If you're using the old `project.name` or very old `project_id` keys in your `.arcconfig`, remove them. In most cases, `arc` will be able to figure out which repository it should use automatically. You can use `arc which` to verify this. If `arc which` can not identify the repository, use `repository.callsign` in `.arcconfig` to specify it explicitly. Refer to the output of `arc which` for more details. **How do I update Herald rules?** Instead of using "Arcanist Project" rules, use "Repository" rules. You can add "Affected Paths" or "Affected Package" conditions to increase the power and specificity of "Repository" conditions. The Owners tool is badly overdue for modernization; if you run into difficulty using it to define packages in order to replace "Arcanist Project" rules, let us know. **How do I update symbol indexing?** Symbols are now indexed per-repository. The indexing script uses repositories and configuration has moved to Diffusion. You may need to tweak any helper scripts you maintain. See T8235 for pending documentation updates.

Long ago, Phabricator organized code primarily in terms of "Arcanist Projects". These were roughly human-readable labels for subdirectories in a repository, like "frontend-server" or "internal-tools". This was somewhat natural in large SVN repositories, where one repository often contained multiple logical projects (each with its own independent codebase and rulesets), and these were the first kind of repositories Phabricator worked with (at Facebook, circa 2007). Subversion is much less popular now than it was in 2007, and Git and Mercurial are much more popular. With Git and Mercurial, it is far more common to organize code in many different repositories, where each repository is one logical project. In this case, the concept of "arcanist projects" isn't useful, because they always map directly to repository roots but add an unnecessary layer of indirection, complexity, and confusion. To make this problem worse, "projects" have become a much more core part of the product, and many users experience significant confusion when they learn that "arcanist projects" and "projects" are entirely separate things, even though they basically have the same name. Phabricator's integration with repositories and tooling for segmenting rulesets for a codebase has improved over time, and we've reduced the importance of "arcanist projects". Circa 2011 they were mandatory; circa 2012-2013 they became optional; we are now removing them entirely. We believe they are virtually unused by modern installs and that installs with large SVN repositories now have other tools available which can serve the same purposes in almost all cases without requiring us to retain this confusing relic of a bygone era. --- FAQ ====== **What are "Arcanist Projects"? Are these the same as "Projects"?** "Arcanist Projects" are not the same as "Projects". One of the reasons we are removing arcanist projects is that they are often a source of confusion, precisely because they have such a similar name. Arcanist projects were completely separate, and configured in the very old {nav Repositories > Arcanist Projects} UI. If you use Git or Mercurial and/or started using Phabricator in the last two years, there's a good chance you've never encountered them and this change may not affect you at all. **Are you removing "Projects"?** No. Projects are a cornerstone of the product, and all our plans around them involve improving them and making them more useful. --- Updating ======= **How do I update `.arcconfig`?** If you're using the old `project.name` or very old `project_id` keys in your `.arcconfig`, remove them. In most cases, `arc` will be able to figure out which repository it should use automatically. You can use `arc which` to verify this. If `arc which` can not identify the repository, use `repository.callsign` in `.arcconfig` to specify it explicitly. Refer to the output of `arc which` for more details. **How do I update Herald rules?** Instead of using "Arcanist Project" rules, use "Repository" rules. You can add "Affected Paths" or "Affected Package" conditions to increase the power and specificity of "Repository" conditions. The Owners tool is badly overdue for modernization; if you run into difficulty using it to define packages in order to replace "Arcanist Project" rules, let us know. **How do I update symbol indexing?** Symbols are now indexed per-repository. The indexing script uses repositories and configuration has moved to Diffusion. You may need to tweak any helper scripts you maintain. See T8235 for pending documentation updates.