[Cosmo-dev] Cosmo release frequency

Travis Vachon travis at osafoundation.org
Tue Oct 9 11:36:24 PDT 2007


I think the biggest barriers to using Git for this process are the  
install and learning curve.

Assuming git and git-svn have been installed correctly and a "git-svn  
gateway" repository has been created, the basic lifecycle for a  
feature, as proposed, would look like this:

git checkout -b <feature_branch_name> remotes/trunk
# check out a new branch named feature_branch_name based on trunk

...
# work

git commit -a
# commit all changes to the local git repository (this could also be  
"git commit ./" or "git commit foo.java")

git checkout remotes/trunk
# switch back to the Subversion trunk tracking branch

git merge <feature_branch_name>
# merge the feature branch to the Subversion trunk tracking branch

git svn fetch
# make sure the remote tracking branch is up to date

git svn dcommit --dry-run
# double check what you're about to push to subversion

git svn dcommit
# push difference between current trunk tracking branch and actual  
remote trunk to Subversion repository in a single commit



If two people are collaborating on a feature, we'd probably have 3  
more steps after "git commit -a" above:

git push <remote_repository_name>  <feature_branch_name>
# push to a public git repository to share work with other folks

git pull <remote_repository_name> /<remote_branch_name>
# pull in a remote branch

git merge <remote_repository_name>/<remote_branch_name>
# merge a remote branch into the current branch



Painless? No, though it gets intuitive pretty quickly.


In contrast, a similar workflow in Subversion would probably look like:

svn copy <trunk_url> <branch_url>
svn co <branch_url>
...
svn ci
cd TRUNK_CHECKOUT
svn merge PATH_TO_BRANCH_CHECKOUT -r  
<pre_branch_commit_rev>:<latest_branch_commit_rev>
svn ci



Sharing with other folks would be normal commits and updates.


Probably the biggest win from using Git would be the (mostly)  
painless merging of multiple remote branches into a local branch. For  
example, if both Bobby and Matthew are working on features I depend  
on in my feature branch, I can just go ahead and grab them with:

git merge <br_repository_name>/<br_feature_branch>
git merge <mde_repository_name>/<mde_feature_branch>

and push those merges + my work public with

git push <my_public_repos>


I'm not sure this is a silver bullet, and I'm not sure it's for  
everyone, but I do think it's worth trying!

-Travis


On Oct 9, 2007, at 7:34 AM, Randy Letness wrote:

> Brian Moseley wrote:
>> if we are going to do two week cycles, then we should expect the vast
>> majority of work to be done on branches. it would not make sense to
>> have much "work in process" on the trunk
>
> Right, features and fixes would be pushed to trunk once they are  
> completed, which means a branch per feature/fix.  So the trunk  
> would always be stable and we would just release from trunk every  
> two or four or  x weeks.  Using svn it would be painful, but if  
> using something else like git makes this trivial then I'm game.
>
> -Randy
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list