Version Control

Who's working on this

ToshioKuratomi abadger1999 toshio@fedoraproject.org Bazaar; possibly Mercurial
Paulo Santos paulobanon
John Kraal geonetix
WarrenTogami warren
Mike Mcgrath mmcgrath Subversion
JesseKeating f13 Mercurial git
Kristian Hoegsberg (git)
JeffOllie (git)

Current System

Rough guide to how the current system works

Current Pain Points

No atomic commits
Not being able to work offline (cvs add needs a server, wtf.)
Adding sources can be "weird", can easily clobber existing sources
Can't handle big files well
CVS bogons/bonghits/grimlins/websuckage
Prohibitively expensive to reconstruct infrastructure outside our environment
Better handling of force-tag
Commits are SLOW!!!
Common dir, wtf.
Really really unreliable (especially with a lot of actions or continuous actions)
Prep work to get into package source control is done outside of source control. No opportunity to learn the tools

Requirements

Unix accounts or certificate based authentication
Access Control Lists of per-package per-branch granularity
Ideally this means per-directory ACL's
ACLs will allow view and commit access to select contributors.
Embargo branches should be on the same server as the normal branches. This is necessary to allow certain upstream developers to work in cooperation with Fedora maintainers.
We need to scale up to hundreds of branches per package in the long run.
Some package/branches would be read-only to most users.
Other package/branches need to be completely hidden from most users.
E-mail notification when changes occur. These notifications must be sent from the server, and it must be not possible for users to bypass.
Distributed SCM allows easy sub-collections of the distribution to be built and tested independently, then the bulk be easily merged back while minimizing effort.
Translations for core packages are right now implemented via cvs.fedora.redhat.com and tied to CVS. More longterm they might also benefit from a more modern version control system.
Be able to track patches separately from the upstream source so that source rpms can easily be created.
Be able to have a continuous development "branch"
Be able to create release "branches" for doing updates for existing Fedora releases. Release "branches" should inherit history of the repo up until the release happened.
Be able to re-create source rpm used to generate any shipped build at any time later, including same version of any helper scripts or metadata used.
Be able to checkout only a given package and not the entire package tree
Be able to be queried and pulled from anonymously (by the buildsystem, by the web, etc.
Be able to trigger scripts such as pre/post commit
be able to reliably disseminate commits as they happen to a selected group of people (per package; branch)
Be useful for offline development
Consistency across all modules for scripted actions like rebuilds
Easy between-branch merging for those who like to ship the same source rpm everywhere
Ideally, not rely on magic 'branch' files for the build & tag-fu to work
Be able to easily rebase/refresh a patch
be able to easily verify a repository consistency
be useful with generic protocols (e.g. http, rsync)
be script-able (for local customization, for integration with rpmbuild, ...)
be able to make (and verify) a signed commit/tag
be able to keep track of details about patches (author, committer, some special marks (e.g. "signed-of-by", "reviewed-by", ...)
be able to generate statistics about patches (diffstat)
be able to generate change logs
Be able to recursive grep sources for identifiable bug patterns
Integration with bugzilla and friends
Push button "pull latest upstream source"
Easy to assemble system outside of our infrastructure
Visible branches
Better handling of dead patches
Enforce 'make prep' like pre-checks
No possibility of commits without notifications
Integration with automated testflows
Integration with Bodhi (linkbacks, etc...)