Who's working on this
- ToshioKuratomi abadger1999 firstname.lastname@example.org Bazaar; possibly Mercurial
- Paulo Santos paulobanon
- John Kraal geonetix
- WarrenTogami warren
- Mike Mcgrath mmcgrath Subversion
- JesseKeating f13 Mercurial
- Kristian Hoegsberg (git)
- JeffOllie (git)
Rough guide to how the current system works
- 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...)
3rd party Resources and Opinions
Version Control System Comparison -
covers just about everything except git and bzr now covers everything
Quick Reference Guide to Free Software Decentralized Revision Control Systems
OpenSolaris comparison of Git, Mercurial and Bazaar-NG (at version 0.7)
Supplements the previous, well documented comparison with Performance enhancements from bzr 0.8 => 0.9.
Something that Ubuntu is thinking about
-  http://live.gnome.org/DistributedSCM GNOME comparison
-  http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws
Xorg is maintaining a rough wishlist of what would they like to see changed in git.