From Fedora Project Wiki
(noting that the comparison covers git and bzr now)
(→‎Requirements: Add things that came up during FUDCon 10.)
Line 32: Line 32:
 
* 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 ==
  

Revision as of 20:20, 26 May 2009


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
  • Kristian Hoegsberg (git)
  • JeffOllie (git)

Current System

Rough guide to how the current system works

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.