From Fedora Project Wiki
fp-wiki>ImportUser
(Imported from MoinMoin)
 
(Added Mozilla mercurial wishlist)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!-- Do not remove
+
{{header|infra}}
-->
 
<!-- StartHeader
 
-->
 
<pre>#!html
 
<div style="height:66px; width:100%; background-color:#002867;">
 
<a href = "http://fedoraproject.org/wiki/Infrastructure"> <img style="float:right;padding-top:3px;" src="http://fedoraproject.org/wiki/Infrastructure?action=AttachFile&do=get&target=InfrastructureTeamN1.png" /></a>
 
</div>
 
 
 
<HR style="height:2px; background-color:#00578E;" />
 
</pre>
 
<!-- EndHeader
 
-->
 
  
 
= Version Control =
 
= Version Control =
 
 
  
 
{{Anchor|Who}}
 
{{Anchor|Who}}
Line 24: 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 46: 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 ==
  
 
* [1]  http://better-scm.berlios.de/comparison/comparison.html
 
* [1]  http://better-scm.berlios.de/comparison/comparison.html
Version Control System Comparison - covers just about everything except git and bzr
+
Version Control System Comparison - <strike>covers just about everything except git and bzr</strike> now covers everything
 
* [2]  http://zooko.com/revision_control_quick_ref.html
 
* [2]  http://zooko.com/revision_control_quick_ref.html
 
Quick Reference Guide to Free Software Decentralized Revision Control
 
Quick Reference Guide to Free Software Decentralized Revision Control
Line 66: 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