From Fedora Project Wiki
(noting that the comparison covers git and bzr now)
(Added Mozilla mercurial wishlist)
 
(3 intermediate revisions by one other user not shown)
Line 10: Line 10:
* WarrenTogami warren
* WarrenTogami warren
* Mike Mcgrath mmcgrath Subversion
* Mike Mcgrath mmcgrath Subversion
* JesseKeating f13 Mercurial
* JesseKeating f13 Mercurial git
* Kristian Hoegsberg (git)
* Kristian Hoegsberg (git)
* JeffOllie (git)
* JeffOllie (git)


{{Anchor|Old}}
{{Anchor|Old}}
== Current System ==
== Current System ==
Rough guide to how the [[/Current|  current system works]]  
Rough guide to how the [[/Current|  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
 


{{Anchor|Requirements}}
{{Anchor|Requirements}}
Line 32: Line 47:
* 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.
* 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.
* 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...)


Highly Desirable Abilities:
* Ability to check out only a portion of the tree in order to work on only a package, instead of the entire tree.
{{Anchor|OutsideComparisons}}
{{Anchor|OutsideComparisons}}
== 3rd party Resources and Opinions ==
== 3rd party Resources and Opinions ==


Line 52: Line 96:
* [7]  http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws
* [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.
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


[[Category:Infrastructure]]
[[Category:Infrastructure]]

Latest revision as of 13:34, 18 June 2010

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