From Fedora Project Wiki
fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (Cleanup.)
(One intermediate revision by the same user 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 67: Line 53:
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.


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

Revision as of 21:35, 25 May 2008


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.

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.

3rd party Resources and Opinions

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

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.