On Mon, 2007-06-18 at 13:57 -0500, Mike McGrath wrote: > So there's a great deal of discussion about the Fedora Packaging SCM its > time we look at the Infrastructure SCM. We now host cvs, hg, git and > svn. For our configuration management we're using for our development. > For many items we've actually created hosted sites (smolt, mirror > manager) seems appropriate for these project which, in theory, are > useful to others. But what about some of our other development where a > hosted project would be wasted? This would be like, kindofblue (our > wiki theme) or a plone plugin. We're using cvs for this right now in > the fedora repo. I think we should do some clean up on this repo but > while we're doing its good to evaluate whether or not to move to > something else or to continue using it. > Can we consolidate a bunch of these into one or more hosted repositories? It's a small step better than our current situation of multiple cvs modules in multiple cvs repositories. Whatever we choose, I've come to believe that a distributed SCM would be good for anything that's not private. (and even some things that are). There are some small pieces of code that end up being worked on at the same time (for instance, the cvsadmin scripts) and having them in a distributed scm would make it easier for people to merge their changes in or merge changes from the repository into their local changes. Additionally, I've started working with people who are new to infrastructure. It's nice to be able to branch a repository and say go to town to someone rather than having them stuck trying to manage patches to the mainline until we're comfortable giving them commit access to the main tree. P.S. I like bzr because it combines the feature(s) I actually liked from svn with the distributed nature of hg, git, etc. I'm not a fan of hg but think it's mq plugin is a great feature. I abhor git :-) The main conceptual difference I've found in bzr and hg so far is that hg seems to work on a repository paradigm whereas bzr works on a branch paradigm[1]_. In hg you clone a repository. Then you end up working on one of many possible tips within your local repo. If you merge from someone else, you first import it into your repository. Then you have to merge the changes from that HEAD and resolve the conflicts in your working tree. In bzr, you branch a branch. There is a single head within that branch. You merge changes to your working copy when you want (and the history of the changes from the other branch is saved in your branch.) svn users will find this very familiar as bzr branches are a new directory tree just like svn branches. Since bzr is distributed, though, it gives you the ability to merge between these branches without having to remember what your last merge was. bzr also makes tags an attribute of a commit rather than svn's "It's a branch that you agree not to edit". [1]_: bzr has a repository format that is optimized storage for branches. You can create a repository in a directory. Then any branches you create in the directory will share storage where things are held in common. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
