This is indeed a great article and the way POCO should take ...

Franky


On 10/17/2012 09:25 AM, Gregoire Aujay wrote:
Hello,

please have a look at this branching model:
http://nvie.com/posts/a-successful-git-branching-model/

It might answer a lot of your questions.

Regards,

Grégoire


On Wed, Oct 17, 2012 at 8:15 AM, Günter Obiltschnig <guenter.obiltschnig@appinf.com> wrote:
I'm fine with that (master corresponds to latest release).
Still think that one Git repository that has 1.4 and master/1.5 in different branches is a better approach. It's also easier to import from SVN that way and we don't lose the history.

Question to git experts: when we do it that way, what is the cost when I check out a specific branch (e.g., 1.4.4 or 1.5.0) from GitHub. Will git copy the entire repository with all history (bad thing) or just the files relevant for specific branch?

--
Günter Obiltschnig
Applied Informatics Software Engineering GmbH
A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096

Company Registration: FN 276491 f | Landesgericht Klagenfurt
Managing Director: DI Günter Obiltschnig



On 17.10.2012, at 07:29, Aleksandar Fabijanic wrote:

> I like that model, seems better suited for git; there should be two separate repositories then - 1.4 and 1.5
>
> Aleksandar Fabijanic
>
> Sent from my iPhone
>
> On Oct 16, 2012, at 22:10, Franky Braem <franky.braem@gmail.com> wrote:
>
>> In my projects I do it as follow: I immediately create a branch for the next version from the master and start developing in that branch. When the version is released I merge it to the master. So the master always is the latest released version.
>>
>> Franky
>>
>> Sent from my Android
>>
>> Op 16 okt. 2012 20:55 schreef "Günter Obiltschnig" <guenter.obiltschnig@appinf.com> het volgende:
>> Well, essentially we only have two branches to work on, master (ex trunk) and 1.4.4/5.
>> Ongoing development should happen in master*. When it's time to release we create a release branch (e.g., 1.5.1) from master.
>> Release branches then essentially become read-only, except for patches (e.g. those nasty patch releases).
>>
>> Since working with branches (including merging) should be really easy in git (at least that's what the git people say...), this should not be an issue.
>>
>> * That actually means, ongoing development happens in local repositories or maybe even private branches, with suitable changes then pushed to master.
>>
>> --
>> Günter Obiltschnig
>> Applied Informatics Software Engineering GmbH
>> A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
>> P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096
>>
>> Company Registration: FN 276491 f | Landesgericht Klagenfurt
>> Managing Director: DI Günter Obiltschnig
>>
>>
>>
>> On 16.10.2012, at 20:35, Alex Fabijanic wrote:
>>
>> > I agree, given the ease and visibility of github forking, there is no need for sandbox. Old SF SVN is still up and anyone can get a chunk of it out, start a github repo and propose/get it added to Poco master when ready.
>> >
>> > In regards to trunk:
>> >
>> > Shall we still keep trunk or should we just go with release branches? Multiple branches are a pain to keep in sync and I'm already concerned enough about keeping 1.5 synced with 1.4. Add trunk to the mix and we are setting ourselves for failure.
>> >
>> > I vote for no more than two active branches at any given time, meaning 1.4 and 1.5 branches only at this time.
>> >
>> > Aleksandar Fabijanic
>> >
>> > Sent from my iPhone
>> >
>> > On Oct 16, 2012, at 11:23, Franky Braem <franky.braem@gmail.com> wrote:
>> >
>> >> To me the word sandbox means playing around (with POCO). Maybe we can
>> >> have some repository where we can put real contributions. Some projects
>> >> that don't need to be part of POCO, but are build with POCO and can be
>> >> useful for others (my MongoDB for example). Unlike the sandbox, where a
>> >> lot of unfinished code is stored, these contributions must follow the
>> >> same standard rules as the POCO core. Instead of writing code in the
>> >> sandbox, I would write the code first in my forked repository and only
>> >> pull it when I think it is ready for others to use. So I don't think we
>> >> need a specific sandbox repository anymore.
>> >>
>> >> just my thoughts,
>> >>
>> >> Franky.
>> >>
>> >> On 10/16/2012 08:07 PM, Günter Obiltschnig wrote:
>> >>> Hi,
>> >>>
>> >>> I'm thinking about how to create and organize the POCO repository on GitHub.
>> >>> My plan for now is to create a local git repository using svn2git from our SourceForge SVN repository, but importing only the trunk and branches.
>> >>> Following command does this (already tested):
>> >>>
>> >>> $ svn2git https://poco.svn.sourceforge.net/svnroot/poco/poco --exclude trunk-1.1 --exclude trunk-1.2 --exclude articles --trunk trunk --branches branches --notags --authors ~/pocosvnusers.txt --no-minimize-url
>> >>>
>> >>> Then I would delete all old branches prior to 1.4.0. I don't think it makes sense to import the complete POCO history over to GitHub.
>> >>> The resulting local git repository would then be pushed to the GitHub poco repository.
>> >>> I will then create a separate repository for the sandbox. We can then decide which sandbox projects we'll transfer over to GitHub.
>> >>>
>> >>> The advantage of this approach would be that we have both 1.4 and trunk/1.5 in the same GitHub repository (as opposed to my original plan of having separate repositories), just in different branches. That means less confusion for users.
>> >>>
>> >>> Any comments?
>> >>>
>> >>> Günter
>> >>>
>> >>> --
>> >>> Günter Obiltschnig
>> >>> Applied Informatics Software Engineering GmbH
>> >>> A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
>> >>> P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096
>> >>>
>> >>> Company Registration: FN 276491 f | Landesgericht Klagenfurt
>> >>> Managing Director: DI Günter Obiltschnig
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> >>> Deploy New Relic app performance management and know exactly
>> >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> >>> http://p.sf.net/sfu/newrelic-dev2dev
>> >>> _______________________________________________
>> >>> poco-develop mailing list
>> >>> poco-develop@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/poco-develop
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Don't let slow site performance ruin your business. Deploy New Relic APM
>> >> Deploy New Relic app performance management and know exactly
>> >> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> >> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> >> http://p.sf.net/sfu/newrelic-dev2dev
>> >> _______________________________________________
>> >> poco-develop mailing list
>> >> poco-develop@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/poco-develop
>> >>
>> >
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> poco-develop mailing list
>> poco-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/poco-develop


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
poco-develop mailing list
poco-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poco-develop



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct


_______________________________________________
poco-develop mailing list
poco-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poco-develop