[Insight-developers] SimpleITK - now using next branch

Gabe Hart gabe.hart at kitware.com
Thu Mar 17 17:16:59 EDT 2011


I think the idea is that once a topic is done (for us, I think that 
would be "Resolved" in Jira), the primary developer for it will merge it 
into master.  This could happen after other developers have QA'd it, or 
just whenever the primary developer decides they're 100% sure it's ready 
to go.  I think once it's merged to master, it should be "Closed" in Jira.

I can certainly relate to git being a learning curve.  It helps to sit 
right next to a git expert (thanks Casey)!

-Gabe

On 03/17/2011 05:09 PM, Daniel Blezek wrote:
> Gabe,
>
>   OK, that makes more sense to me.  When are we going to start?  and 
> who will keep master and next in step?
>
>   I guess I was thinking that next would be a "meta-topic" branch. 
>  Really, I don't have any strong opinions at all, given my poor git 
> track record...  Brad just tells me what to do and I do it...
>
> Cheers,
> -dan
>
>
> On 3/17/11 4:06 PM, "Gabe Hart" <gabe.hart at kitware.com> wrote:
>
>       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:
>
>         Re: SimpleITK - now using next branch 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
>
>
>
>
>
> -- 
> *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/ced868ea/attachment-0001.htm>


More information about the Insight-developers mailing list