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

• [1] http://better-scm.berlios.de/comparison/comparison.html

Version Control System Comparison - covers just about everything except git and bzr now covers everything

• [2] http://zooko.com/revision_control_quick_ref.html

Quick Reference Guide to Free Software Decentralized Revision Control Systems

• [3] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html

OpenSolaris comparison of Git, Mercurial and Bazaar-NG (at version 0.7)

• [4] http://bazaar-vcs.org/Performance/0.9

Supplements the previous, well documented comparison with Performance enhancements from bzr 0.8 => 0.9.

• [5] https://wiki.ubuntu.com/NoMoreSourcePackages

Something that Ubuntu is thinking about

• [6] http://live.gnome.org/DistributedSCM GNOME comparison
• [7] http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws

Xorg is maintaining a rough wishlist of what would they like to see changed in git.

• [8] https://developer.mozilla.org/en/Mercurial%2f%2fDesired_Features

Similar list from Mozilla for Mercurial