arch を使うのが初めての人はよく、アーカイブ構造の厳格な構成に 驚くようです。よくある二つの質問(と答え)は:

どうしてカテゴリ、ブランチ、バージョンなどという概念が あるのか? どうして好きな文字列でプロジェクトの名前をつけることができない のか? この質問は、リビジョン管理システムがライブラリ管理システム である、ということを思い出せば理解できると思います。 その仕事のひとつは、非常に大きなプロジェクトやソースコードの集まりを 閲覧したり検索したりするのを支援することです。そのような検索を現実的なものにするため、 arch はカテゴリシステムを定義しています: つまり、カテゴリ、ブランチ、バージョンがそれです。 (リビジョン管理とは何か?項参照)

これは、デューイの分類表のような、本のライブラリで使われるカテゴリシステム に何か似ているところもあります: ライブラリにあるすべては階層的に カテゴリ化されています。それは、あるアイテムがどこに保管されているかを 示すための統一的な方法で、さまざまなアイテム間の関係を示唆することによって 検索を支援します。たとえば、ブランチは同じカテゴリ中のほかのブランチとよく 似ているはずです。大きなメジャーバージョン番号を持ったディレクトリは、 同じブランチにある、より小さなメジャーバージョン番号を持ったものよりも あとで作られた作業を含んでいるはずです。

この類推は完全ではありません: デューイのような本のカタログシステムは、公式な カテゴリとサブカテゴリのリストに基づいていますが、archでは 自分でカテゴリ名を選ぶことができます。しかし、それでもなおarch は検索や閲覧を簡単にするために、関連するアイテムのグループ化のアイディアに 基づいています。そして、デューイが人々がどのようにして本を検索するかという 共通のパターンを把握することを意図していたのと同様、arch もソースアーカイブ中を人々がどのように検索するかという共通のパターンを捉える ことを意図しています。

なぜ、バージョン番号は二つの部分を持っているのか? 人によっては<major>.<minor> バージョン番号の 制約を好きになれないようです:0.1のかわりに、0.1.1 のような番号体系を好む、などです。

実際、この制約は、最終的にはarchから取り除かれることになるでしょう。 しかし現時点では、二つのバージョン番号体系の統一性は、unix の標準的なsort プログラムを使って、arch のバージョン番号の任意のリストをソートする ことをより簡単なものとしています。archは、sort のような標準的なツールと簡単に連携できることに非常に大きなプライオリティをおいています。