[pgrouting-dev] Using gitflow to standardize branching

[Daniel Kastl]

Hi Kishore,

Thanks for counting the branches! I haven't counted them till today. ;-)
And the blog post is also good!

Well, there are the branches:

  remotes/origin/darp
  remotes/origin/debian
  remotes/origin/debian-karmic
  remotes/origin/debian-maverick
  remotes/origin/debian-natty
  remotes/origin/devel-2_0
  remotes/origin/gsoc-multimodal
  remotes/origin/gsoc-tdsp
  remotes/origin/master
  remotes/origin/pristine-tar
  remotes/origin/snapshot
  remotes/origin/snapshot-maverick
  remotes/origin/unittests
  remotes/origin/upstream

Indeed there are many branches, but most of them you don't really need to
worry about.

There are several branches for making debian/ubuntu packages, because
git-buildpackage is some nice way to also handle packaging with version
control. I counted 8 branches altogether.
Because there were small changes with different versions of Ubuntu I made
different branches for them. Maybe I should do this in my own fork instead.

So when you leave them away, there are the following branches left:

   - remotes/origin/darp
   -> contains DARP algorithm, should be merged with 2.0
   - remotes/origin/devel-2_0
   -> should be used for 2.0 development and will be merged into master,
   when 2.0 is out
   - remotes/origin/gsoc-multimodal
   -> for GSoC
   - remotes/origin/gsoc-tdsp
   -> for GSoC
   - remotes/origin/unittests
   -> can also go to 2.0, right?

I think this number is acceptable, isn't it?
Sorry for the mess with the the branches for packaging. I just left the
Karmic branch for example, even if it won't be supported anymore.

Daniel

On Sun, Aug 7, 2011 at 5:14 PM, Kishore Kumar <justjkk at gmail.com> wrote:

> Hi,
>
> Please checkout this blogpost[1] about a successful branching model in
> git. I see pgrouting currently has 14 branches and the flow is a bit
> confusing. So, shall we slowly transition from the current branches to
> the git-flow style workflow?
> The transition involves the following:
> * 'master' -> 'develop' // Current master becomes the develop branch
> * 'tag v1.05' -> 'master' // Latest release point becomes the new master
> branch
> * 'unittests' -> 'feature/unittests' // unittests branch becomes a
> feature branch
> * 'gsoc-*' -> 'feature/gsoc-*' // gsoc branches become feature branches
> * 'darp' -> 'feature/darp' // darp branch becomes feature branch
> * 'devel-2_0' is not required and changes are moved to 'develop'
>
> gitflow doesn't tell anything about packaging branches. So, I'm
> confused on how to transition them.
> Requesting daniel to take this further.
>
> Thanks,
> J Kishore kumar.
>
> [1] - http://nvie.com/posts/a-successful-git-branching-model/
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>



-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110807/197da7f8/attachment.html