[Insight-developers] SimpleITK - now using next branch

Gabe Hart gabe.hart at kitware.com
Thu Mar 17 17:06:43 EDT 2011


Hmmm... I guess we're looking at two slightly different workflows (I'll 
call them yours and mine, but I'm very up for discussion).  Here are a 
couple of points about the two:

In yours, topics can only go into next once they are completely 
finished, otherwise future topics may be based off of buggy versions of 
the topic.  Your master branch is essentially equivalent to a set of 
tags that point out stable locations in the history of next.  Also, once 
a topic is merged into next it is really hard to remove it because other 
work will depend on it.

In mine, the next branch acts as an integration branch where mostly 
finished topics get merged to make sure that they play well together.  
Once a topic is fully matured it gets merged into next AND merged into 
master, so master stays relatively current with next.  This way when 
branches are based off of master, your are working on the most current 
"Fully stable" version of the toolkit.  This model really works best 
when there's some sort of QA step inserted between the initial merge to 
next and the final merge to master and next.

For our purposes, I'm not sure that mine is necessary unless we insert 
some sort of QA step into our process.  Again, I think I missed some of 
the initial discussion on switching to the next/master workflow, so my 
method may not be at all what was talked about there.

-Gabe

On 03/17/2011 04:41 PM, Daniel Blezek wrote:
> Hi Gabe,
>
>   Can you enlighten me a bit here.  If we don't bring changes back 
> into master, how can I build on what is currently being done in SimpleITK?
>
> Should I do this?
>
> git checkout --b SIMPLEITK-1-some-work origin/master
> git rebase origin/next   # Should I do this? is this bad?
> git commit
> git commit
> git checkout origin/next
> git merge ---no-ff SIMPLEITK-1-some-work
>
>
> Is this right?  It's goes a bit in the face of some of the other 
> guides I've seen.
>
> http://nvie.com/posts/a-successful-git-branching-model/
> http://robertelwell.info/blog/git-svn-wrap-up/
>
> My understanding is that we should create topic branches from "next", 
> and merge them back into next.  When we are ready for a "release", we 
> merge next into master.
>
> Is this incorrect?
>
> Thanks,
> -dan
>
>
>
>
> On 3/17/11 10:21 AM, "Gabe Hart" <gabe.hart at kitware.com> wrote:
>
>       Shoot... one more thing I forgot that has probably already been
>     discussed, but is really important.  All topic branches MUST be
>     based on master and not next.  I got into a lot of trouble by
>     basing things on dev (our version of next) when I first started
>     using this workflow.
>
>      -Gabe
>
>      On 03/17/2011 10:58 AM, Bradley Lowekamp wrote:
>
>         Gabe,
>
>
>
>         Please share that check. I only had the following:
>
>
>
>
>
>         if( NOT ITK_USE_REVIEW )
>         # TODO need to check ITK configuration to verify that it has
>         the needed modules
>         #  message(FATAL_ERROR "Please reconfigure ITK by turning
>         ITK_USE_REVIEW ON")
>         endif()
>
>
>          Brad
>
>
>
>
>
>
>
>
>
>
>         On Mar 17, 2011, at 10:50 AM, Gabe Hart wrote:
>
>
>
>              Good catch.  I remember some discussion about using next,
>             but then was out of the loop for a while, so I haven't
>             been good about checking what is already in next.  I'll
>             try to be better about checking there before I push ahead
>             with new ideas.
>
>              As far as this topic goes, I did manage to get things
>             compiled and linked against the modularized version by
>             just adding a check to see if "ITK-Review" is in the
>             ITK_MODULES_ENABLED list after finding ITK, but all of the
>             tests fail when compiled this way.  I'll abandon this
>             issue since it seems like it's already being taken care of.
>
>              -Gabe
>
>              On 03/17/2011 10:45 AM, Bradley Lowekamp wrote:
>
>                 Gabe,
>
>
>
>                 I see you added a new issue into JIRA that is
>                 basically a duplicate:
>
>
>
>
>                 https://itk.icts.uiowa.edu/jira/browse/SIMPLEITK-23
>
>
>
>
>                 I make the link and commented about the issue.
>
>
>
>
>                 As this has been already addressed and merged in the
>                 next branch, I must ask if you are aware that we are
>                 trying to use the next branch for integration of topics?
>
>
>
>
>                 Brad
>
>
>
>
>                 BTW: I am CC ing the developers list as Luis has
>                 suggested that our off-list SimpleITK discussions
>                 should really be going to the developers list. I would
>                 still like to maintain the convention of including
>                 SimpleITK in the subject, so that mail filtering is easy.
>
>
>
>
>
>
>
>                 ========================================================
>
>                 Bradley Lowekamp
>
>                 Lockheed Martin Contractor for
>
>                 Office of High Performance Computing and Communications
>
>                 National Library of Medicine
>
>                 blowekamp at mail.nih.gov
>
>
>
>
>
>
>
>
>
> -- 
> *Daniel Blezek, PhD
> *Medical Imaging Informatics Innovation Center
>
> P 127 or (77) 8 8886
> T 507 538 8886
> E blezek.daniel at mayo.edu
>
> Mayo Clinic
> 200 First St. S.W.
> Harwick SL-44
> Rochester, MN 55905
> mayoclinic.org
> "It is more complicated than you think." -- RFC 1925


-- 
Gabe Hart
R&D Engineer
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(919) 969-6990 x317

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110317/aa85aaf7/attachment.htm>


More information about the Insight-developers mailing list