Hi Kishore,<div><br></div><div>Thanks for counting the branches! I haven't counted them till today. ;-)</div><div>And the blog post is also good!</div><div><br></div><div>Well, there are the branches:</div><div><br></div>
<div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/darp</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/debian</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/debian-karmic</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/debian-maverick</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/debian-natty</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/devel-2_0</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/gsoc-multimodal</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/gsoc-tdsp</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/master</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/pristine-tar</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/snapshot</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/snapshot-maverick</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/unittests</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> remotes/origin/upstream</font></div>
</div><div><br></div><div>Indeed there are many branches, but most of them you don't really need to worry about.</div><div><br></div><div>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.</div>
<div>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.</div><div><br></div><div>So when you leave them away, there are the following branches left:</div>
<div><ul><li>remotes/origin/darp<br>-> contains DARP algorithm, should be merged with 2.0</li><li>remotes/origin/devel-2_0<br>-> should be used for 2.0 development and will be merged into master, when 2.0 is out</li>
<li>remotes/origin/gsoc-multimodal<br>-> for GSoC</li><li>remotes/origin/gsoc-tdsp<br>-> for GSoC</li><li>remotes/origin/unittests<br>-> can also go to 2.0, right?</li></ul><div>I think this number is acceptable, isn't it?</div>
</div><div>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. </div><div><br></div><div>Daniel<br><br><div class="gmail_quote">On Sun, Aug 7, 2011 at 5:14 PM, Kishore Kumar <span dir="ltr"><<a href="mailto:justjkk@gmail.com">justjkk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Please checkout this blogpost[1] about a successful branching model in<br>
git. I see pgrouting currently has 14 branches and the flow is a bit<br>
confusing. So, shall we slowly transition from the current branches to<br>
the git-flow style workflow?<br>
The transition involves the following:<br>
* 'master' -> 'develop' // Current master becomes the develop branch<br>
* 'tag v1.05' -> 'master' // Latest release point becomes the new master branch<br>
* 'unittests' -> 'feature/unittests' // unittests branch becomes a<br>
feature branch<br>
* 'gsoc-*' -> 'feature/gsoc-*' // gsoc branches become feature branches<br>
* 'darp' -> 'feature/darp' // darp branch becomes feature branch<br>
* 'devel-2_0' is not required and changes are moved to 'develop'<br>
<br>
gitflow doesn't tell anything about packaging branches. So, I'm<br>
confused on how to transition them.<br>
Requesting daniel to take this further.<br>
<br>
Thanks,<br>
J Kishore kumar.<br>
<br>
[1] - <a href="http://nvie.com/posts/a-successful-git-branching-model/" target="_blank">http://nvie.com/posts/a-successful-git-branching-model/</a><br>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66, 99, 171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66, 99, 171)" target="_blank">http://georepublic.de</a></span><br>
</div>