English Portuguese (Portugal)
The _rawhide_ repository
In Rawhide - Fedora's rolling release repository, from which release are Branched before finally going stable - _rawhide_ is the only repository. All package builds are sent there. It is represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-rawhide.repo` file in the repository path. For any system running Rawhide, it should be enabled. For any other system, it should not.
The _rawhide_ repositories for the various primary https://fedoraproject.org/wiki/Architectures[architectures] can be found in the directory on the mirrors, and can also be queried from https://fedoraproject.org/wiki/MirrorManager[MirrorManager]. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 will return mirrors for the x86_64 _fedora_ repository for Rawhide.
_stable_ is not a repository
It is not unusual to see references to the 'stable repository', but this is something of a misnomer. _stable_ is more of a state that can be considered to exist for both Branched releases post https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling[Bodhi enabling] and for stable releases. It consists of package builds that were part of Rawhide at the time they Branched, package builds sent directly to the Branched _fedora_ repository between the branch point and the _Bodhi enabling point_, and package builds that passed the https://fedoraproject.org/wiki/Updates_Policy[Updates Policy] and moved from _updates-testing_ after the _Bodhi enabling point_.
For Branched releases, the _stable_ state is represented solely by the current contents of the _fedora_ repository (and, arguably, the _bleed_ repository, but that is a small case).
For stable releases, the _stable_ state is represented by the contents of the _fedora_ repository combined with the contents of the _updates_ repository.
_stable_ is also a state a package can be considered to be in (or an attribute it can be considered to have) when it has been _pushed stable_ or _tagged stable_ and exists in, or will soon exist in, a _stable_ repository for a release - whichever literal repository that is (see above).
Installation and Product repositories / trees
The repositories referred to above are neither associated with a specific https://fedoraproject.org/wiki/Fedora.next[Fedora.next] _Product_, nor part of an installable tree (a tree containing the necessary files to be used as a base repository by https://fedoraproject.org/wiki/Anaconda[Anaconda], the Fedora installer). Specialized repositories exist for these purposes.
For Fedora.next releases - and later - there is (as of September 2014) no installable tree not associated with a specific Product. The installable trees for various Products can be found under `/fedora/linux/releases/XX/` on the mirrors for stable releases, and under `/fedora/linux/releases/test/` for Branched pre-release milestones. They can also be queried from MirrorManager. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-{FedoraVersionNumberNext}&arch=x86_64 will return mirrors for the x86_64 current installation repository for Server.
These repositories are frozen (new packages are not pushed to them) and are created at various points in the https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle]. A new installation tree (containing a repository) is built for several Products for https://fedoraproject.org/wiki/QA:SOP_compose_request[each test compose or release candidate build], and the trees for the Alpha and Beta releases are made available on the mirrors in the directory (see above). They contain a subset of the full package set that is considered to define each Product.
The Product trees for the GA (Final) release are made available in the `/releases` tree on the mirrors.
At any given point in the release cycle, the MirrorManager request for a Product repository may redirect to a test compose / release candidate tree, a pre-release milestone tree, or the Final release tree.
These repositories are usually not used or enabled by default on installed systems, as for that purpose they are redundant with one of the three primary repositories described above. However, one could use a Product repository in place of the _fedora_ repository to keep a system limited to the Product package set. They are represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-(product).repo` file in the repository path, which may well not be installed on many systems.
Other repositories
There are other repositories that fulfil various niche purposes, which are documented here for the sake of providing a comprehensive reference. They should not usually be significant to the vast majority of Fedora users. None of these repositories is represented in a packaged repository file, enabled by default, or should usually be used in a Fedora installation.
The _bleed_ repository
The _bleed_ repository exists for a single purpose: during https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes], it contains packages that have been granted 'freeze exceptions' via the https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[Blocker Bug Process] or https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[Freeze Exception bug process], and which are desired to be included in the next test compose or release candidate build, but have not yet reached _stable_ state and hence been moved to the _fedora_ repository. In other words, it contains packages explicitly required in TC/RC https://fedoraproject.org/wiki/QA:SOP_compose_request[compose requests].
The _bleed_ repository can be found http://kojipkgs.fedoraproject.org/mash/bleed/[here], but again, is not usually of interest to the vast majority of Fedora users. The packages it contains are always also available from the build system, Koji, and usually from the _updates-testing_ repository.