Infrastructure/VersionControl

= 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...)

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 Xorg is maintaining a rough wishlist of what would they like to see changed in git. Similar list from Mozilla for Mercurial
 * [1] http://better-scm.berlios.de/comparison/comparison.html
 * [2] http://zooko.com/revision_control_quick_ref.html
 * [3] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
 * [4] http://bazaar-vcs.org/Performance/0.9
 * [5] https://wiki.ubuntu.com/NoMoreSourcePackages
 * [6] http://live.gnome.org/DistributedSCM GNOME comparison
 * [7] http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws
 * [8] https://developer.mozilla.org/en/Mercurial%2f%2fDesired_Features