Re: Our SCM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux