Hi All,

As Csound 6 is on the verge of release, I thought it worth discussing
how we will handle branches for development work, bug fixes, etc.
What I'd like to propose is that we switch to using this model:

http://nvie.com/posts/a-successful-git-branching-model/

This model is made much simpler to do with this git plugin:

https://github.com/nvie/gitflow

The main ideas from it are:

1. The "master" branch only contains released code.  It is only merged
to from other branches, and no one commits to it directly.

2. The "develop" branch contains the main development work.

3. Feature branches are branched off "develop"

4. Hotfixes are branched off "master".  These are for fixes to
released code, and allow issuing releases when development work is not
complete.  The code from hotfix branches gets merged back into
"master" and "develop"

5. Release branches are branched off "develop" and used to finalize a
release.  Once that's complete, all changes get merged back into
"master" and "develop".

I've been using this for Blue and found it fairly simple to use,
especially with the plugin, and allows a lot of flexibility. For
example:

- master is always stable
- hotfixes can be done even while development is on-going for the next version
- feature branches can easily be pushed and shared, collaborated on,
and merged back into develop
- the plugin does a lot of the work for you
- the plugin will do tags for a lot of these steps, i.e. if you do
"git flow release finish CSOUND6.01", it will merge with master, tag
with CSOUND6.01, merge back into develop, etc.
- on OSX, git-flow is supported in SourceTree

One of the concerns I have post-6.00 is that we will have users
reporting issues we will need to fix, but we will also have ongoing
development for newer features.  We'll need to be timely with
releases, but also have a means for all of the changes to be sorted
out.  We can do adhoc branching but I think having a well-designed
model that we can all reference will be better.

Of all the branching strategies I've come across between work life and
private research, this has been one of the best solutions I've found.
My thought is if we agree to this, when 6.00 is tagged we can start
the git-flow process by initializing the repo (git flow init) to make
the develop branch and start with this model post-6.00.

Thanks!
steven

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The primary issue I'm seeing that this would help on is the problem we
have of "oh, this new feature is almost done, so let's wait until this
is done to release all these accumulated fixes".  With this model,
there is no dependency for on-going development to be complete to do a
hotfix.  I'm thinking ahead here that post-6.00 things will be a bit
hectic with bug fixes and that it will settle down over time.  I also
know that I have a few things that might be a bit big to develop, and
I both want to be able to share that to get reviews on the code and
testing, but also don't want that to hold up any bug fix releases.

Moving forward, I do have some thoughts on restructuring the grammar
of the parser and how that is compiled.  That would be a large change.
 Again, I'll probably do that in a branch regardless, but then if we
all have our own branching strategies it all becomes adhoc.  At least
with this, there are tools to automate everything, thus simplifying
things.

Also, as an example, let's say we start to use the version numbering of:

Major.Minor.Release

6.00.0  - first major release of 6.0
6.00.1 - first bug fix release
6.00.2 - 2nd bug fix release
6.00.3 - 3rd bug fix release
6.01.0 - first minor release (includes new features)
6.01.1 - etc.

Those bug fix releases can be issued quickly while we continue to
build and develop features for 6.01.

On Tue, Jul 9, 2013 at 10:28 AM, Michael Gogins
 wrote:
> I can't say I've experienced any problems with the current model. Usually my
> work only touches a few files. If it touches more, I just create a local
> branch.
>
> What problems have we been experiencing that this model would resolve? The
> only objection I have to your proposal is a desire to keep things as simple
> as possible.
>
> Best,
> Mike
>
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Jul 9, 2013 at 10:21 AM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> As Csound 6 is on the verge of release, I thought it worth discussing
>> how we will handle branches for development work, bug fixes, etc.
>> What I'd like to propose is that we switch to using this model:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> This model is made much simpler to do with this git plugin:
>>
>> https://github.com/nvie/gitflow
>>
>> The main ideas from it are:
>>
>> 1. The "master" branch only contains released code.  It is only merged
>> to from other branches, and no one commits to it directly.
>>
>> 2. The "develop" branch contains the main development work.
>>
>> 3. Feature branches are branched off "develop"
>>
>> 4. Hotfixes are branched off "master".  These are for fixes to
>> released code, and allow issuing releases when development work is not
>> complete.  The code from hotfix branches gets merged back into
>> "master" and "develop"
>>
>> 5. Release branches are branched off "develop" and used to finalize a
>> release.  Once that's complete, all changes get merged back into
>> "master" and "develop".
>>
>> I've been using this for Blue and found it fairly simple to use,
>> especially with the plugin, and allows a lot of flexibility. For
>> example:
>>
>> - master is always stable
>> - hotfixes can be done even while development is on-going for the next
>> version
>> - feature branches can easily be pushed and shared, collaborated on,
>> and merged back into develop
>> - the plugin does a lot of the work for you
>> - the plugin will do tags for a lot of these steps, i.e. if you do
>> "git flow release finish CSOUND6.01", it will merge with master, tag
>> with CSOUND6.01, merge back into develop, etc.
>> - on OSX, git-flow is supported in SourceTree
>>
>> One of the concerns I have post-6.00 is that we will have users
>> reporting issues we will need to fix, but we will also have ongoing
>> development for newer features.  We'll need to be timely with
>> releases, but also have a means for all of the changes to be sorted
>> out.  We can do adhoc branching but I think having a well-designed
>> model that we can all reference will be better.
>>
>> Of all the branching strategies I've come across between work life and
>> private research, this has been one of the best solutions I've found.
>> My thought is if we agree to this, when 6.00 is tagged we can start
>> the git-flow process by initializing the repo (git flow init) to make
>> the develop branch and start with this model post-6.00.
>>
>> Thanks!
>> steven
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is what I have been doinf for ages

> Also, as an example, let's say we start to use the version numbering of:
>
> Major.Minor.Release
>
> 6.00.0  - first major release of 6.0
> 6.00.1 - first bug fix release
> 6.00.2 - 2nd bug fix release
> 6.00.3 - 3rd bug fix release
> 6.01.0 - first minor release (includes new features)
> 6.01.1 - etc.
>
> Those bug fix releases can be issued quickly while we continue to
> build and develop features for 6.01.
>



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, that makes sense, I do remember these scheduling issues.

Best,
Mike

Sorry, yes, the version numbering isn't the issue, just used as an
illustration. (should have edited before sending!).  What I'm
concerned about are those bug fix releases and development features
interfering with each other, and then more and more pressure builds to
finish a feature because someone says "The system is broken! We can't
use it!  My classes are all dropping Csound!  The world is ending!"
and we have to say "Oh just wait one more day! One more day! Almost
done...."  and, oh wait, that feature broke 10 things at the last
minute. etc. etc.

On Tue, Jul 9, 2013 at 10:52 AM,   wrote:
> This is what I have been doinf for ages
>
>> Also, as an example, let's say we start to use the version numbering of:
>>
>> Major.Minor.Release
>>
>> 6.00.0  - first major release of 6.0
>> 6.00.1 - first bug fix release
>> 6.00.2 - 2nd bug fix release
>> 6.00.3 - 3rd bug fix release
>> 6.01.0 - first minor release (includes new features)
>> 6.01.1 - etc.
>>
>> Those bug fix releases can be issued quickly while we continue to
>> build and develop features for 6.01.
>>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Michael.  To note, I understand fully that suggesting this
would also mean ramp up time for everyone.  However, I think it'd be
worth it for the group.

On Tue, Jul 9, 2013 at 11:52 AM, Michael Gogins
 wrote:
> As I said, your argument makes sense, I agree with your suggestion. My
> memory just needed to be jogged about how often that story had played out.
>
> Best,
> Mike
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Jul 9, 2013 at 11:01 AM, Steven Yi  wrote:
>>
>> Sorry, yes, the version numbering isn't the issue, just used as an
>> illustration. (should have edited before sending!).  What I'm
>> concerned about are those bug fix releases and development features
>> interfering with each other, and then more and more pressure builds to
>> finish a feature because someone says "The system is broken! We can't
>> use it!  My classes are all dropping Csound!  The world is ending!"
>> and we have to say "Oh just wait one more day! One more day! Almost
>> done...."  and, oh wait, that feature broke 10 things at the last
>> minute. etc. etc.
>>
>> On Tue, Jul 9, 2013 at 10:52 AM,   wrote:
>> > This is what I have been doinf for ages
>> >
>> >> Also, as an example, let's say we start to use the version numbering
>> >> of:
>> >>
>> >> Major.Minor.Release
>> >>
>> >> 6.00.0  - first major release of 6.0
>> >> 6.00.1 - first bug fix release
>> >> 6.00.2 - 2nd bug fix release
>> >> 6.00.3 - 3rd bug fix release
>> >> 6.01.0 - first minor release (includes new features)
>> >> 6.01.1 - etc.
>> >>
>> >> Those bug fix releases can be issued quickly while we continue to
>> >> build and develop features for 6.01.
>> >>
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm happy to sign up for that. As soon as a develop branch is there, I'll shift to it.

Victor
On 9 Jul 2013, at 15:21, Steven Yi wrote:

> Hi All,
> 
> As Csound 6 is on the verge of release, I thought it worth discussing
> how we will handle branches for development work, bug fixes, etc.
> What I'd like to propose is that we switch to using this model:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> This model is made much simpler to do with this git plugin:
> 
> https://github.com/nvie/gitflow
> 
> The main ideas from it are:
> 
> 1. The "master" branch only contains released code.  It is only merged
> to from other branches, and no one commits to it directly.
> 
> 2. The "develop" branch contains the main development work.
> 
> 3. Feature branches are branched off "develop"
> 
> 4. Hotfixes are branched off "master".  These are for fixes to
> released code, and allow issuing releases when development work is not
> complete.  The code from hotfix branches gets merged back into
> "master" and "develop"
> 
> 5. Release branches are branched off "develop" and used to finalize a
> release.  Once that's complete, all changes get merged back into
> "master" and "develop".
> 
> I've been using this for Blue and found it fairly simple to use,
> especially with the plugin, and allows a lot of flexibility. For
> example:
> 
> - master is always stable
> - hotfixes can be done even while development is on-going for the next version
> - feature branches can easily be pushed and shared, collaborated on,
> and merged back into develop
> - the plugin does a lot of the work for you
> - the plugin will do tags for a lot of these steps, i.e. if you do
> "git flow release finish CSOUND6.01", it will merge with master, tag
> with CSOUND6.01, merge back into develop, etc.
> - on OSX, git-flow is supported in SourceTree
> 
> One of the concerns I have post-6.00 is that we will have users
> reporting issues we will need to fix, but we will also have ongoing
> development for newer features.  We'll need to be timely with
> releases, but also have a means for all of the changes to be sorted
> out.  We can do adhoc branching but I think having a well-designed
> model that we can all reference will be better.
> 
> Of all the branching strategies I've come across between work life and
> private research, this has been one of the best solutions I've found.
> My thought is if we agree to this, when 6.00 is tagged we can start
> the git-flow process by initializing the repo (git flow init) to make
> the develop branch and start with this model post-6.00.
> 
> Thanks!
> steven
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sounds like we have a majority.

John: any comments/issues?  If you're okay with giving this a try, I
can setup the git-flow pattern and get a develop branch going.

Note: if we give it a try and find we don't like it, it's very easy to
back out of.  We would just merge everything back up to master and
delete all of the develop, feature, and hotfix branches, and then
continue on as we used to.


On Wed, Jul 10, 2013 at 3:05 PM, Victor Lazzarini
 wrote:
> I'm happy to sign up for that. As soon as a develop branch is there, I'll shift to it.
>
> Victor
> On 9 Jul 2013, at 15:21, Steven Yi wrote:
>
>> Hi All,
>>
>> As Csound 6 is on the verge of release, I thought it worth discussing
>> how we will handle branches for development work, bug fixes, etc.
>> What I'd like to propose is that we switch to using this model:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> This model is made much simpler to do with this git plugin:
>>
>> https://github.com/nvie/gitflow
>>
>> The main ideas from it are:
>>
>> 1. The "master" branch only contains released code.  It is only merged
>> to from other branches, and no one commits to it directly.
>>
>> 2. The "develop" branch contains the main development work.
>>
>> 3. Feature branches are branched off "develop"
>>
>> 4. Hotfixes are branched off "master".  These are for fixes to
>> released code, and allow issuing releases when development work is not
>> complete.  The code from hotfix branches gets merged back into
>> "master" and "develop"
>>
>> 5. Release branches are branched off "develop" and used to finalize a
>> release.  Once that's complete, all changes get merged back into
>> "master" and "develop".
>>
>> I've been using this for Blue and found it fairly simple to use,
>> especially with the plugin, and allows a lot of flexibility. For
>> example:
>>
>> - master is always stable
>> - hotfixes can be done even while development is on-going for the next version
>> - feature branches can easily be pushed and shared, collaborated on,
>> and merged back into develop
>> - the plugin does a lot of the work for you
>> - the plugin will do tags for a lot of these steps, i.e. if you do
>> "git flow release finish CSOUND6.01", it will merge with master, tag
>> with CSOUND6.01, merge back into develop, etc.
>> - on OSX, git-flow is supported in SourceTree
>>
>> One of the concerns I have post-6.00 is that we will have users
>> reporting issues we will need to fix, but we will also have ongoing
>> development for newer features.  We'll need to be timely with
>> releases, but also have a means for all of the changes to be sorted
>> out.  We can do adhoc branching but I think having a well-designed
>> model that we can all reference will be better.
>>
>> Of all the branching strategies I've come across between work life and
>> private research, this has been one of the best solutions I've found.
>> My thought is if we agree to this, when 6.00 is tagged we can start
>> the git-flow process by initializing the repo (git flow init) to make
>> the develop branch and start with this model post-6.00.
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

fyi.... and this is "always sad" to me....

two students did drop Csound this summer because of all the crashing and confusion.

Sent from my iPad

On Jul 9, 2013, at 11:01 AM, Steven Yi  wrote:

> Sorry, yes, the version numbering isn't the issue, just used as an
> illustration. (should have edited before sending!).  What I'm
> concerned about are those bug fix releases and development features
> interfering with each other, and then more and more pressure builds to
> finish a feature because someone says "The system is broken! We can't
> use it!  My classes are all dropping Csound!  The world is ending!"
> and we have to say "Oh just wait one more day! One more day! Almost
> done...."  and, oh wait, that feature broke 10 things at the last
> minute. etc. etc.
> 
> On Tue, Jul 9, 2013 at 10:52 AM,   wrote:
>> This is what I have been doinf for ages
>> 
>>> Also, as an example, let's say we start to use the version numbering of:
>>> 
>>> Major.Minor.Release
>>> 
>>> 6.00.0  - first major release of 6.0
>>> 6.00.1 - first bug fix release
>>> 6.00.2 - 2nd bug fix release
>>> 6.00.3 - 3rd bug fix release
>>> 6.01.0 - first minor release (includes new features)
>>> 6.01.1 - etc.
>>> 
>>> Those bug fix releases can be issued quickly while we continue to
>>> build and develop features for 6.01.
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Look very complicated to me.  As git is such a pain anyway this looks
like a recipe for lots of confusion.

Actually I am not sure what problem  you are trying to solve.

How does a plugin (to what?) help.

==John ffitch
>>>>> "Steven" == Steven Yi  writes:

 Steven> Hi All,
 Steven> As Csound 6 is on the verge of release, I thought it worth discussing
 Steven> how we will handle branches for development work, bug fixes, etc.
 Steven> What I'd like to propose is that we switch to using this model:

 Steven> http://nvie.com/posts/a-successful-git-branching-model/

 Steven> This model is made much simpler to do with this git plugin:

 Steven> https://github.com/nvie/gitflow

 Steven> The main ideas from it are:

 Steven> 1. The "master" branch only contains released code.  It is only merged
 Steven> to from other branches, and no one commits to it directly.

 Steven> 2. The "develop" branch contains the main development work.

 Steven> 3. Feature branches are branched off "develop"

 Steven> 4. Hotfixes are branched off "master".  These are for fixes to
 Steven> released code, and allow issuing releases when development work is not
 Steven> complete.  The code from hotfix branches gets merged back into
 Steven> "master" and "develop"

 Steven> 5. Release branches are branched off "develop" and used to finalize a
 Steven> release.  Once that's complete, all changes get merged back into
 Steven> "master" and "develop".

 Steven> I've been using this for Blue and found it fairly simple to use,
 Steven> especially with the plugin, and allows a lot of flexibility. For
 Steven> example:

 Steven> - master is always stable
 Steven> - hotfixes can be done even while development is on-going for the next version
 Steven> - feature branches can easily be pushed and shared, collaborated on,
 Steven> and merged back into develop
 Steven> - the plugin does a lot of the work for you
 Steven> - the plugin will do tags for a lot of these steps, i.e. if you do
 Steven> "git flow release finish CSOUND6.01", it will merge with master, tag
 Steven> with CSOUND6.01, merge back into develop, etc.
 Steven> - on OSX, git-flow is supported in SourceTree

 Steven> One of the concerns I have post-6.00 is that we will have users
 Steven> reporting issues we will need to fix, but we will also have ongoing
 Steven> development for newer features.  We'll need to be timely with
 Steven> releases, but also have a means for all of the changes to be sorted
 Steven> out.  We can do adhoc branching but I think having a well-designed
 Steven> model that we can all reference will be better.

 Steven> Of all the branching strategies I've come across between work life and
 Steven> private research, this has been one of the best solutions I've found.
 Steven> My thought is if we agree to this, when 6.00 is tagged we can start
 Steven> the git-flow process by initializing the repo (git flow init) to make
 Steven> the develop branch and start with this model post-6.00.

 Steven> Thanks!
 Steven> steven


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi John,

I've already iterated issues that were concerns of mine, but they boil down to:

- bug fix releases can go out without pulling in current feature
development work (the bug fix is applied to a branch off master, which
has only code for releases).  In this case, we can all work at our own
pace for new features, but we can still respond to a bug that needs to
be released.  The bug fixed branch, upon completion, automatically
gets merged back into master and develop branches.

For example, if we are all working on new features for 6.01.0, and
there's a number of bugs reported for 6.00.0 (as there have been
already for arrays), what happens?  Let's say I've already pushed some
work to git and it's working but not fully tested, you and Victor and
Michael all have other things pushed and we're developing for 6.01.0,
and we get more and more bugs.  In the past, users have either had to
wait for us to finish or tie off our dev work somehow so that we could
release a bug fixed+semi-complete features version of csound, or
developers had to wait out a freeze to push anything while only bug
fixes were done.

With the git-flow model, all of the 6.01.0 work can go safely into the
develop branch.  Bug fixes to the current release can go into a hotfix
branch and released (6.00.1), and that is separate from the current
development work.  The git-flow model takes into account merging the
hotfix released code back into master as well as back into develop.
Everything stays in sync, and it's all automated with the git-flow
plugin for git.


- development work can be organized into small dev changes (in the
develop branch) and larger, long term dev work in feature branches
branched from develop. Sharing long term feature branches is useful to
get others to collaborate and test.

For example, I have plans to re-look at the grammar and compiler to
see about making it more generic.  It'd potentially change a lot of
code.  I don't want to interfere with anyone else's work, but I do
want to share it so others could look at it and test and help develop.
 With the current system, I can make a branch from master and publish
it, and later merge.  With git-flow, this is essentially the same
thing, but with the git-flow plugin, there's a standardized method for
dealing with this scenario. The git-flow plugin has:

Steven-Yis-MacBook-Pro:blue stevenyi$ git flow feature help
usage: git flow feature [list] [-v]
       git flow feature start [-F]  []
       git flow feature finish [-rFk] 
       git flow feature publish 
       git flow feature track 
       git flow feature diff []
       git flow feature rebase [-i] []
       git flow feature checkout []
       git flow feature pull  []

I can do "git flow feature start NewParser develop" to start a new
feature branch, and use the finish command to complete that branch.
git-flow will then merge, tag, etc. everything for you.

- the first link sent describes the model for branching
(http://nvie.com/posts/a-successful-git-branching-model/); the second
link sent is a GIT plugin you install locally that will automate all
of the git branching/merging for you
(https://github.com/nvie/gitflow).


My argument for all this is that git and distributed development in
general is not easy, regardless of version control system.  I think
the git-flow model helps to solve a lot of issues, and actually makes
git development easier in that it has names for things we want to do
(create a hotfix, create feature branch, etc.), rather than trying to
remember to branch, tag, etc. everything. Also, it ensures code
changes get re-merged into all the right places.

Thanks!
steven

On Thu, Jul 11, 2013 at 12:09 PM, jpff  wrote:
> Look very complicated to me.  As git is such a pain anyway this looks
> like a recipe for lots of confusion.
>
> Actually I am not sure what problem  you are trying to solve.
>
> How does a plugin (to what?) help.
>
> ==John ffitch
>>>>>> "Steven" == Steven Yi  writes:
>
>  Steven> Hi All,
>  Steven> As Csound 6 is on the verge of release, I thought it worth discussing
>  Steven> how we will handle branches for development work, bug fixes, etc.
>  Steven> What I'd like to propose is that we switch to using this model:
>
>  Steven> http://nvie.com/posts/a-successful-git-branching-model/
>
>  Steven> This model is made much simpler to do with this git plugin:
>
>  Steven> https://github.com/nvie/gitflow
>
>  Steven> The main ideas from it are:
>
>  Steven> 1. The "master" branch only contains released code.  It is only merged
>  Steven> to from other branches, and no one commits to it directly.
>
>  Steven> 2. The "develop" branch contains the main development work.
>
>  Steven> 3. Feature branches are branched off "develop"
>
>  Steven> 4. Hotfixes are branched off "master".  These are for fixes to
>  Steven> released code, and allow issuing releases when development work is not
>  Steven> complete.  The code from hotfix branches gets merged back into
>  Steven> "master" and "develop"
>
>  Steven> 5. Release branches are branched off "develop" and used to finalize a
>  Steven> release.  Once that's complete, all changes get merged back into
>  Steven> "master" and "develop".
>
>  Steven> I've been using this for Blue and found it fairly simple to use,
>  Steven> especially with the plugin, and allows a lot of flexibility. For
>  Steven> example:
>
>  Steven> - master is always stable
>  Steven> - hotfixes can be done even while development is on-going for the next version
>  Steven> - feature branches can easily be pushed and shared, collaborated on,
>  Steven> and merged back into develop
>  Steven> - the plugin does a lot of the work for you
>  Steven> - the plugin will do tags for a lot of these steps, i.e. if you do
>  Steven> "git flow release finish CSOUND6.01", it will merge with master, tag
>  Steven> with CSOUND6.01, merge back into develop, etc.
>  Steven> - on OSX, git-flow is supported in SourceTree
>
>  Steven> One of the concerns I have post-6.00 is that we will have users
>  Steven> reporting issues we will need to fix, but we will also have ongoing
>  Steven> development for newer features.  We'll need to be timely with
>  Steven> releases, but also have a means for all of the changes to be sorted
>  Steven> out.  We can do adhoc branching but I think having a well-designed
>  Steven> model that we can all reference will be better.
>
>  Steven> Of all the branching strategies I've come across between work life and
>  Steven> private research, this has been one of the best solutions I've found.
>  Steven> My thought is if we agree to this, when 6.00 is tagged we can start
>  Steven> the git-flow process by initializing the repo (git flow init) to make
>  Steven> the develop branch and start with this model post-6.00.
>
>  Steven> Thanks!
>  Steven> steven
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think this is the main thing you need to understand about git. Branching is everywhere, even your local commits are a branch that needs to be merged back. Once I understood that, git has been my friend.

Cheers,
Andres

Maybe it's because there's more people working simultaneously on the same sections of code?

I have found that having a good three way merge program is indispensable with git.

Cheers,
Andres

I mean a program that can merge the local, remote and current conflict file simultaneously, allowing manual edits of each.

I think conflicts in git will only occur if the same section of the file has been modified. Otherwise the merge succeeds, but you generally have to have an additional commit for the merge (this commit is often empty - i.e. no diff - as there are no conflicts) because your local changes are a branch which needs merging back.

Cheers,
Andres

Most of the time the commit is automatic. But I think you hit the nail on the head, code cleanup will tend to have more conflicts that other more localized commits.

Would there be any other reason why git would produce more conflicts than svn? I don't think merging algorithms in git are inferior to svn's. But I don't really know...

Cheers,
Andres

I'm a bit of a lurker, so, pardon my butting in.  I suggest that a BOF on
git take place at the second conference.

Thanks,

/ken

On 07/11/2013 05:31 PM, Justin Smith wrote:
> For my usage, many problems can be avoided by not using the pull command.
> Pull is a fetch followed by an auto-merge - and often you can preempt
> conflicts by doing an explicit fetch, looking at the state of upstream,
> and then manually merging on a file by file basis.
> 
> 
> On Thu, Jul 11, 2013 at 5:18 PM, Andres Cabrera  > wrote:
> 
>     Sorry meant merging by git or cvs (for some reason I though csound
>     was in svn, but now I remember it wasn't).
> 
>     Cheers,
>     Andrés
> 
> 
>     On Thu, Jul 11, 2013 at 12:22 PM, Victor Lazzarini
>     > wrote:
> 
>         Not sure, I've never used svn myself.
> 
>         On 11 Jul 2013, at 20:18, Andres Cabrera wrote:
> 
>>         Most of the time the commit is automatic. But I think you hit
>>         the nail on the head, code cleanup will tend to have more
>>         conflicts that other more localized commits.
>>
>>         Would there be any other reason why git would produce more
>>         conflicts than svn? I don't think merging algorithms in git are
>>         inferior to svn's. But I don't really know...
>>
>>         Cheers,
>>         Andres
>>
>>         On Jul 11, 2013 12:13 PM, "Victor Lazzarini"
>>         > wrote:
>>
>>             So you mean something more than just the git command? 
>>             I have only observed merge conflicts that I head to go and
>>             fix manually and then commit again; these will 99% of the
>>             time occur
>>             when pulling from the repo. I've never had to do an
>>             additional commit, or had empty commits as you describe.
>>
>>             I know John does a lot of code beautification, and that is
>>             possibly where it all goes wrong, as it tends to modify
>>             lots of files.
>>
>>             In any case, I think Steven's idea of using a devel branch
>>             is sound. I think it will help us to do further development
>>             without 
>>             making it difficult to fix bugs in the released code.
>>
>>             Victor
>>             On 11 Jul 2013, at 20:03, Andres Cabrera wrote:
>>
>>>             I mean a program that can merge the local, remote and
>>>             current conflict file simultaneously, allowing manual
>>>             edits of each.
>>>
>>>             I think conflicts in git will only occur if the same
>>>             section of the file has been modified. Otherwise the merge
>>>             succeeds, but you generally have to have an additional
>>>             commit for the merge (this commit is often empty - i.e. no
>>>             diff - as there are no conflicts) because your local
>>>             changes are a branch which needs merging back.
>>>
>>>             Cheers,
>>>             Andres
>>>
>>>             On Jul 11, 2013 11:53 AM, "Victor Lazzarini"
>>>             >>             > wrote:
>>>
>>>                 That would explain some of the merge fails, but not
>>>                 all. Look at the log messages, sometimes one out of
>>>                 three commit messages from jpff are "git in a mess again".
>>>                 What is the "three way merge program" you are talking
>>>                 about? Not sure I follow.
>>>
>>>                 Victor
>>>
>>>                 On 11 Jul 2013, at 19:48, Andres Cabrera wrote:
>>>
>>>>                 Maybe it's because there's more people working
>>>>                 simultaneously on the same sections of code?
>>>>
>>>>                 I have found that having a good three way merge
>>>>                 program is indispensable with git.
>>>>
>>>>                 Cheers,
>>>>                 Andres
>>>>
>>>>                 On Jul 11, 2013 11:41 AM, "Victor Lazzarini"
>>>>                 >>>                 > wrote:
>>>>
>>>>                     From what I could observe (and his comments),
>>>>                     John's troubles with GIT were constant failed
>>>>                     merges. I am not sure why he had so many of them,
>>>>                     as only occasionally myself I would get these
>>>>                     problems. I agree that failed merges are a pain,
>>>>                     and a good thing about CVS was that it really seldom
>>>>                     happened there (to me).
>>>>                     On 11 Jul 2013, at 19:30, Andres Cabrera wrote:
>>>>
>>>>>                     I think this is the main thing you need to
>>>>>                     understand about git. Branching is everywhere,
>>>>>                     even your local commits are a branch that needs
>>>>>                     to be merged back. Once I understood that, git
>>>>>                     has been my friend.
>>>>>
>>>>>                     Cheers,
>>>>>                     Andres
>>>>>
>>>>>                     On Jul 11, 2013 9:40 AM, "Justin Smith"
>>>>>                     >>>>                     > wrote:
>>>>>
>>>>>                         This model is standard in my workplace and I
>>>>>                         can no longer imagine sanely maintaining
>>>>>                         code and adding features without it. I think
>>>>>                         a key insight here is that in git branching
>>>>>                         and merging are simple operations that
>>>>>                         should be done frequently.
>>>>>
>>>>>
>>>>>                         On Thu, Jul 11, 2013 at 9:34 AM, Steven Yi
>>>>>                         >>>>                         > wrote:
>>>>>
>>>>>                             Hi John,
>>>>>
>>>>>                             I've already iterated issues that were
>>>>>                             concerns of mine, but they boil down to:
>>>>>
>>>>>                             - bug fix releases can go out without
>>>>>                             pulling in current feature
>>>>>                             development work (the bug fix is applied
>>>>>                             to a branch off master, which
>>>>>                             has only code for releases).  In this
>>>>>                             case, we can all work at our own
>>>>>                             pace for new features, but we can still
>>>>>                             respond to a bug that needs to
>>>>>                             be released.  The bug fixed branch, upon
>>>>>                             completion, automatically
>>>>>                             gets merged back into master and develop
>>>>>                             branches.
>>>>>
>>>>>                             For example, if we are all working on
>>>>>                             new features for 6.01.0, and
>>>>>                             there's a number of bugs reported for
>>>>>                             6.00.0 (as there have been
>>>>>                             already for arrays), what happens?
>>>>>                              Let's say I've already pushed some
>>>>>                             work to git and it's working but not
>>>>>                             fully tested, you and Victor and
>>>>>                             Michael all have other things pushed and
>>>>>                             we're developing for 6.01.0,
>>>>>                             and we get more and more bugs.  In the
>>>>>                             past, users have either had to
>>>>>                             wait for us to finish or tie off our dev
>>>>>                             work somehow so that we could
>>>>>                             release a bug fixed+semi-complete
>>>>>                             features version of csound, or
>>>>>                             developers had to wait out a freeze to
>>>>>                             push anything while only bug
>>>>>                             fixes were done.
>>>>>
>>>>>                             With the git-flow model, all of the
>>>>>                             6.01.0 work can go safely into the
>>>>>                             develop branch.  Bug fixes to the
>>>>>                             current release can go into a hotfix
>>>>>                             branch and released (6.00.1), and that
>>>>>                             is separate from the current
>>>>>                             development work.  The git-flow model
>>>>>                             takes into account merging the
>>>>>                             hotfix released code back into master as
>>>>>                             well as back into develop.
>>>>>                             Everything stays in sync, and it's all
>>>>>                             automated with the git-flow
>>>>>                             plugin for git.
>>>>>
>>>>>
>>>>>                             - development work can be organized into
>>>>>                             small dev changes (in the
>>>>>                             develop branch) and larger, long term
>>>>>                             dev work in feature branches
>>>>>                             branched from develop. Sharing long term
>>>>>                             feature branches is useful to
>>>>>                             get others to collaborate and test.
>>>>>
>>>>>                             For example, I have plans to re-look at
>>>>>                             the grammar and compiler to
>>>>>                             see about making it more generic.  It'd
>>>>>                             potentially change a lot of
>>>>>                             code.  I don't want to interfere with
>>>>>                             anyone else's work, but I do
>>>>>                             want to share it so others could look at
>>>>>                             it and test and help develop.
>>>>>                              With the current system, I can make a
>>>>>                             branch from master and publish
>>>>>                             it, and later merge.  With git-flow,
>>>>>                             this is essentially the same
>>>>>                             thing, but with the git-flow plugin,
>>>>>                             there's a standardized method for
>>>>>                             dealing with this scenario. The git-flow
>>>>>                             plugin has:
>>>>>
>>>>>                             Steven-Yis-MacBook-Pro:blue stevenyi$
>>>>>                             git flow feature help
>>>>>                             usage: git flow feature [list] [-v]
>>>>>                                    git flow feature start [-F]
>>>>>                              []
>>>>>                                    git flow feature finish [-rFk]
>>>>>                             
>>>>>                                    git flow feature publish 
>>>>>                                    git flow feature track 
>>>>>                                    git flow feature diff
>>>>>                             []
>>>>>                                    git flow feature rebase [-i]
>>>>>                             []
>>>>>                                    git flow feature checkout
>>>>>                             []
>>>>>                                    git flow feature pull 
>>>>>                             []
>>>>>
>>>>>                             I can do "git flow feature start
>>>>>                             NewParser develop" to start a new
>>>>>                             feature branch, and use the finish
>>>>>                             command to complete that branch.
>>>>>                             git-flow will then merge, tag, etc.
>>>>>                             everything for you.
>>>>>
>>>>>                             - the first link sent describes the
>>>>>                             model for branching
>>>>>                             (http://nvie.com/posts/a-successful-git-branching-model/);
>>>>>                             the second
>>>>>                             link sent is a GIT plugin you install
>>>>>                             locally that will automate all
>>>>>                             of the git branching/merging for you
>>>>>                             (https://github.com/nvie/gitflow).
>>>>>
>>>>>
>>>>>                             My argument for all this is that git and
>>>>>                             distributed development in
>>>>>                             general is not easy, regardless of
>>>>>                             version control system.  I think
>>>>>                             the git-flow model helps to solve a lot
>>>>>                             of issues, and actually makes
>>>>>                             git development easier in that it has
>>>>>                             names for things we want to do
>>>>>                             (create a hotfix, create feature branch,
>>>>>                             etc.), rather than trying to
>>>>>                             remember to branch, tag, etc.
>>>>>                             everything. Also, it ensures code
>>>>>                             changes get re-merged into all the right
>>>>>                             places.
>>>>>
>>>>>                             Thanks!
>>>>>                             steven
>>>>>
>>>>>                             On Thu, Jul 11, 2013 at 12:09 PM, jpff
>>>>>                             >>>>                             > wrote:
>>>>>                             > Look very complicated to me.  As git
>>>>>                             is such a pain anyway this looks
>>>>>                             > like a recipe for lots of confusion.
>>>>>                             >
>>>>>                             > Actually I am not sure what problem
>>>>>                              you are trying to solve.
>>>>>                             >
>>>>>                             > How does a plugin (to what?) help.
>>>>>                             >
>>>>>                             > ==John ffitch
>>>>>                             >>>>>> "Steven" == Steven Yi
>>>>>                             >>>>                             > writes:
>>>>>                             >
>>>>>                             >  Steven> Hi All,
>>>>>                             >  Steven> As Csound 6 is on the verge
>>>>>                             of release, I thought it worth discussing
>>>>>                             >  Steven> how we will handle branches
>>>>>                             for development work, bug fixes, etc.
>>>>>                             >  Steven> What I'd like to propose is
>>>>>                             that we switch to using this model:
>>>>>                             >
>>>>>                             >  Steven>
>>>>>                             http://nvie.com/posts/a-successful-git-branching-model/
>>>>>                             >
>>>>>                             >  Steven> This model is made much
>>>>>                             simpler to do with this git plugin:
>>>>>                             >
>>>>>                             >  Steven> https://github.com/nvie/gitflow
>>>>>                             >
>>>>>                             >  Steven> The main ideas from it are:
>>>>>                             >
>>>>>                             >  Steven> 1. The "master" branch only
>>>>>                             contains released code.  It is only merged
>>>>>                             >  Steven> to from other branches, and
>>>>>                             no one commits to it directly.
>>>>>                             >
>>>>>                             >  Steven> 2. The "develop" branch
>>>>>                             contains the main development work.
>>>>>                             >
>>>>>                             >  Steven> 3. Feature branches are
>>>>>                             branched off "develop"
>>>>>                             >
>>>>>                             >  Steven> 4. Hotfixes are branched off
>>>>>                             "master".  These are for fixes to
>>>>>                             >  Steven> released code, and allow
>>>>>                             issuing releases when development work
>>>>>                             is not
>>>>>                             >  Steven> complete.  The code from
>>>>>                             hotfix branches gets merged back into
>>>>>                             >  Steven> "master" and "develop"
>>>>>                             >
>>>>>                             >  Steven> 5. Release branches are
>>>>>                             branched off "develop" and used to
>>>>>                             finalize a
>>>>>                             >  Steven> release.  Once that's
>>>>>                             complete, all changes get merged back into
>>>>>                             >  Steven> "master" and "develop".
>>>>>                             >
>>>>>                             >  Steven> I've been using this for Blue
>>>>>                             and found it fairly simple to use,
>>>>>                             >  Steven> especially with the plugin,
>>>>>                             and allows a lot of flexibility. For
>>>>>                             >  Steven> example:
>>>>>                             >
>>>>>                             >  Steven> - master is always stable
>>>>>                             >  Steven> - hotfixes can be done even
>>>>>                             while development is on-going for the
>>>>>                             next version
>>>>>                             >  Steven> - feature branches can easily
>>>>>                             be pushed and shared, collaborated on,
>>>>>                             >  Steven> and merged back into develop
>>>>>                             >  Steven> - the plugin does a lot of
>>>>>                             the work for you
>>>>>                             >  Steven> - the plugin will do tags for
>>>>>                             a lot of these steps, i.e. if you do
>>>>>                             >  Steven> "git flow release finish
>>>>>                             CSOUND6.01", it will merge with master, tag
>>>>>                             >  Steven> with CSOUND6.01, merge back
>>>>>                             into develop, etc.
>>>>>                             >  Steven> - on OSX, git-flow is
>>>>>                             supported in SourceTree
>>>>>                             >
>>>>>                             >  Steven> One of the concerns I have
>>>>>                             post-6.00 is that we will have users
>>>>>                             >  Steven> reporting issues we will need
>>>>>                             to fix, but we will also have ongoing
>>>>>                             >  Steven> development for newer
>>>>>                             features.  We'll need to be timely with
>>>>>                             >  Steven> releases, but also have a
>>>>>                             means for all of the changes to be sorted
>>>>>                             >  Steven> out.  We can do adhoc
>>>>>                             branching but I think having a well-designed
>>>>>                             >  Steven> model that we can all
>>>>>                             reference will be better.
>>>>>                             >
>>>>>                             >  Steven> Of all the branching
>>>>>                             strategies I've come across between work
>>>>>                             life and
>>>>>                             >  Steven> private research, this has
>>>>>                             been one of the best solutions I've found.
>>>>>                             >  Steven> My thought is if we agree to
>>>>>                             this, when 6.00 is tagged we can start
>>>>>                             >  Steven> the git-flow process by
>>>>>                             initializing the repo (git flow init) to
>>>>>                             make
>>>>>                             >  Steven> the develop branch and start
>>>>>                             with this model post-6.00.
>>>>>                             >
>>>>>                             >  Steven> Thanks!
>>>>>                             >  Steven> steven
>>>>>                             >
>>>>>                             >
>>>>>                             >
>>>>>                             ------------------------------------------------------------------------------
>>>>>                             > See everything from the browser to the
>>>>>                             database with AppDynamics
>>>>>                             > Get end-to-end visibility with
>>>>>                             application monitoring from AppDynamics
>>>>>                             > Isolate bottlenecks and diagnose root
>>>>>                             cause in seconds.
>>>>>                             > Start your free trial of AppDynamics
>>>>>                             Pro today!
>>>>>                             >
>>>>>                             http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>>>                             >
>>>>>                             _______________________________________________
>>>>>                             > Csound-devel mailing list
>>>>>                             > Csound-devel@lists.sourceforge.net
>>>>>                             
>>>>>                             >
>>>>>                             https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>                             ------------------------------------------------------------------------------
>>>>>                             See everything from the browser to the
>>>>>                             database with AppDynamics
>>>>>                             Get end-to-end visibility with
>>>>>                             application monitoring from AppDynamics
>>>>>                             Isolate bottlenecks and diagnose root
>>>>>                             cause in seconds.
>>>>>                             Start your free trial of AppDynamics Pro
>>>>>                             today!
>>>>>                             http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>>>                             _______________________________________________
>>>>>                             Csound-devel mailing list
>>>>>                             Csound-devel@lists.sourceforge.net
>>>>>                             
>>>>>                             https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>>                         ------------------------------------------------------------------------------
>>>>>                         See everything from the browser to the
>>>>>                         database with AppDynamics
>>>>>                         Get end-to-end visibility with application
>>>>>                         monitoring from AppDynamics
>>>>>                         Isolate bottlenecks and diagnose root cause
>>>>>                         in seconds.
>>>>>                         Start your free trial of AppDynamics Pro today!
>>>>>                         http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>>>                         _______________________________________________
>>>>>                         Csound-devel mailing list
>>>>>                         Csound-devel@lists.sourceforge.net
>>>>>                         
>>>>>                         https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>                     ------------------------------------------------------------------------------
>>>>>                     See everything from the browser to the database
>>>>>                     with AppDynamics
>>>>>                     Get end-to-end visibility with application
>>>>>                     monitoring from AppDynamics
>>>>>                     Isolate bottlenecks and diagnose root cause in
>>>>>                     seconds.
>>>>>                     Start your free trial of AppDynamics Pro today!
>>>>>                     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>>>>>                     Csound-devel mailing list
>>>>>                     Csound-devel@lists.sourceforge.net
>>>>>                     
>>>>>                     https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>                     Dr Victor Lazzarini
>>>>                     Senior Lecturer
>>>>                     Dept. of Music
>>>>                     NUI Maynooth Ireland
>>>>                     tel.: +353 1 708 3545 
>>>>                     Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>>                     ------------------------------------------------------------------------------
>>>>                     See everything from the browser to the database
>>>>                     with AppDynamics
>>>>                     Get end-to-end visibility with application
>>>>                     monitoring from AppDynamics
>>>>                     Isolate bottlenecks and diagnose root cause in
>>>>                     seconds.
>>>>                     Start your free trial of AppDynamics Pro today!
>>>>                     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>>                     _______________________________________________
>>>>                     Csound-devel mailing list
>>>>                     Csound-devel@lists.sourceforge.net
>>>>                     
>>>>                     https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>                 ------------------------------------------------------------------------------
>>>>                 See everything from the browser to the database with
>>>>                 AppDynamics
>>>>                 Get end-to-end visibility with application monitoring
>>>>                 from AppDynamics
>>>>                 Isolate bottlenecks and diagnose root cause in seconds.
>>>>                 Start your free trial of AppDynamics Pro today!
>>>>                 http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>>>>                 Csound-devel mailing list
>>>>                 Csound-devel@lists.sourceforge.net
>>>>                 
>>>>                 https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>                 Dr Victor Lazzarini
>>>                 Senior Lecturer
>>>                 Dept. of Music
>>>                 NUI Maynooth Ireland
>>>                 tel.: +353 1 708 3545 
>>>                 Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>>                 ------------------------------------------------------------------------------
>>>                 See everything from the browser to the database with
>>>                 AppDynamics
>>>                 Get end-to-end visibility with application monitoring
>>>                 from AppDynamics
>>>                 Isolate bottlenecks and diagnose root cause in seconds.
>>>                 Start your free trial of AppDynamics Pro today!
>>>                 http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>                 _______________________________________________
>>>                 Csound-devel mailing list
>>>                 Csound-devel@lists.sourceforge.net
>>>                 
>>>                 https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>             ------------------------------------------------------------------------------
>>>             See everything from the browser to the database with
>>>             AppDynamics
>>>             Get end-to-end visibility with application monitoring from
>>>             AppDynamics
>>>             Isolate bottlenecks and diagnose root cause in seconds.
>>>             Start your free trial of AppDynamics Pro today!
>>>             http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>>>             Csound-devel mailing list
>>>             Csound-devel@lists.sourceforge.net
>>>             
>>>             https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>             Dr Victor Lazzarini
>>             Senior Lecturer
>>             Dept. of Music
>>             NUI Maynooth Ireland
>>             tel.: +353 1 708 3545 
>>             Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>             ------------------------------------------------------------------------------
>>             See everything from the browser to the database with
>>             AppDynamics
>>             Get end-to-end visibility with application monitoring from
>>             AppDynamics
>>             Isolate bottlenecks and diagnose root cause in seconds.
>>             Start your free trial of AppDynamics Pro today!
>>             http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>             _______________________________________________
>>             Csound-devel mailing list
>>             Csound-devel@lists.sourceforge.net
>>             
>>             https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>         ------------------------------------------------------------------------------
>>         See everything from the browser to the database with AppDynamics
>>         Get end-to-end visibility with application monitoring from
>>         AppDynamics
>>         Isolate bottlenecks and diagnose root cause in seconds.
>>         Start your free trial of AppDynamics Pro today!
>>         http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
>>         Csound-devel mailing list
>>         Csound-devel@lists.sourceforge.net
>>         
>>         https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
>         Dr Victor Lazzarini
>         Senior Lecturer
>         Dept. of Music
>         NUI Maynooth Ireland
>         tel.: +353 1 708 3545 
>         Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
>         ------------------------------------------------------------------------------
>         See everything from the browser to the database with AppDynamics
>         Get end-to-end visibility with application monitoring from
>         AppDynamics
>         Isolate bottlenecks and diagnose root cause in seconds.
>         Start your free trial of AppDynamics Pro today!
>         http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>         _______________________________________________
>         Csound-devel mailing list
>         Csound-devel@lists.sourceforge.net
>         
>         https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
>     ------------------------------------------------------------------------------
>     See everything from the browser to the database with AppDynamics
>     Get end-to-end visibility with application monitoring from AppDynamics
>     Isolate bottlenecks and diagnose root cause in seconds.
>     Start your free trial of AppDynamics Pro today!
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Csound-devel mailing list
>     Csound-devel@lists.sourceforge.net
>     
>     https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> In any case, I think Steven's idea of using a devel branch is
> sound. I think it will help us to do further development without
> making it difficult to fix bugs in the released code. 

Can someone produce a simple workflow as how this is supposed to
work?  At present I have a small set of scripts that sometimes work.

I tend to use different computers for different attempts -- that was
how all the parallelism stuff was done.  I am concerned about disk
space and my experience of changing between branches on one machine
was less than stellar

==John ffitch

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sun, Jul 14, 2013 at 12:12 PM, john ffitch  wrote:
> Can someone produce a simple workflow as how this is supposed to
> work?  At present I have a small set of scripts that sometimes work


The idea is to move the development work (what is
currently done in the master branch) to a 'develop' branch. This means
that the master branch is reserved for released code. Development goes
on as usual in the develop branch[1]. The key difference is when the need
arises of releasing a bugfix release: a hotfix branch is started off
the master branch, commits are done, and finally the release made. This is not
radically different than what is currently done.

The git flow workflow is just a series of conventions plus a tool that
aid in this workflow. By "hardcoding" names for the hotfix and topic
branches (if any are desired), it can help do all required
merges so that for example cs 6.01 does not miss any fixes done to
6.00.1, and that new features are not accidentally merged for bugfix
releases.

Hope this helps


[1] optionally, for large features one may want to start a feature branch
--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think this is where John is finding that GIT does not work well for him, I am guessing, because I see always lots of
layout fixes when merges have failed. Maybe we should agree on what layout standards we should use so that he
does not need to be fixing it with a script.

Victor
On 16 Jul 2013, at 05:04, John Lato wrote:

> if you want to make big formatting/whitespace/layout changes, make commits that only affect layout and put them on develop as soon as possible.
> 
> The reason for both of these is that refactors and especially layout changes tend to cause a lot of merge conflicts.  You don't want to leave them languishing in a feature branch where the pain is delayed.  You want to put them into the develop branch as soon as possible.  Then you can base your own feature branches from develop and have the changes in your working codebase, and you don't have to deal with merging because it's already done.  This means that everyone else will need to merge the changes into their own feature branches, but that's ok because they know how to do so better than you.  And if they follow point 2 above, they'll be able to merge them quickly and be done with it, which will in turn make future merges simpler.

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Except that does not explain it.  I change one file which only I use I
think (SuSE rom spec) commit it and pull from SF.  It fails and I have to
fix it up.

> I think this is where John is finding that GIT does not work well for him,
> I am guessing, because I see always lots of
> layout fixes when merges have failed. Maybe we should agree on what layout
> standards we should use so that he
> does not need to be fixing it with a script.
>
> Victor
> On 16 Jul 2013, at 05:04, John Lato wrote:
>
>> if you want to make big formatting/whitespace/layout changes, make
>> commits that only affect layout and put them on develop as soon as
>> possible.
>>
>> The reason for both of these is that refactors and especially layout
>> changes tend to cause a lot of merge conflicts.  You don't want to leave
>> them languishing in a feature branch where the pain is delayed.  You
>> want to put them into the develop branch as soon as possible.  Then you
>> can base your own feature branches from develop and have the changes in
>> your working codebase, and you don't have to deal with merging because
>> it's already done.  This means that everyone else will need to merge the
>> changes into their own feature branches, but that's ok because they know
>> how to do so better than you.  And if they follow point 2 above, they'll
>> be able to merge them quickly and be done with it, which will in turn
>> make future merges simpler.
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Usually rock solid if slow by USA standards (8Mb down, 0.3Mb up).

> Do you have a reliable network connection? If the connection drops while
> things are happening it messes GIT up.
>
> Regards,
> Mike
>
>

 On Tue, Jul 16, 2013 at 5:22 AM,  wrote:
>
>> Except that does not explain it.  I change one file which only I use I
>> think (SuSE rom spec) commit it and pull from SF.  It fails and I have
>> to
>> fix it up.



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Changing one file but getting a merge error when it's not conflicting
with any other changes is definitely odd. However, if the master repo
has moved on and you've moved forward with your local branch, it's
normal to require a merge on pull there but it usually doesn't have
conflicts at all.  What kind of error message do you get with merging,
and what file conflicts do you get?

On Tue, Jul 16, 2013 at 9:29 AM,   wrote:
> Usually rock solid if slow by USA standards (8Mb down, 0.3Mb up).
>
>> Do you have a reliable network connection? If the connection drops while
>> things are happening it messes GIT up.
>>
>> Regards,
>> Mike
>>
>>
>
>  On Tue, Jul 16, 2013 at 5:22 AM,  wrote:
>>
>>> Except that does not explain it.  I change one file which only I use I
>>> think (SuSE rom spec) commit it and pull from SF.  It fails and I have
>>> to
>>> fix it up.
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> What kind of error message do you get with merging,
> and what file conflicts do you get?
>

E325: ATTENTION
Found a swap file by the name ".git/.MERGE_MSG.swp"
          owned by: jpff   dated: Wed Nov 21 12:06:59 2012
         file name: ~jpff/Sourceforge/csound/New/csound6/.git/MERGE_MSG
          modified: YES
         user name: jpff   host name: harvey
        process ID: 2787
While opening file ".git/MERGE_MSG"
             dated: Tue Jul 16 19:59:16 2013
      NEWER than swap file!


> On Tue, Jul 16, 2013 at 9:29 AM,   wrote:
>> Usually rock solid if slow by USA standards (8Mb down, 0.3Mb up).
>>
>>> Do you have a reliable network connection? If the connection drops
>>> while
>>> things are happening it messes GIT up.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>
>>  On Tue, Jul 16, 2013 at 5:22 AM,  wrote:
>>>
>>>> Except that does not explain it.  I change one file which only I use I
>>>> think (SuSE rom spec) commit it and pull from SF.  It fails and I have
>>>> to
>>>> fix it up.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Jul 16, 2013 3:01 PM, <jpff@cs.bath.ac.uk> wrote:
>
> > What kind of error message do you get with merging,
> > and what file conflicts do you get?
> >
>
> E325: ATTENTION
> Found a swap file by the name ".git/.MERGE_MSG.swp"
>           owned by: jpff   dated: Wed Nov 21 12:06:59 2012
>          file name: ~jpff/Sourceforge/csound/New/csound6/.git/MERGE_MSG
>           modified: YES
>          user name: jpff   host name: harvey
>         process ID: 2787
> While opening file ".git/MERGE_MSG"
>              dated: Tue Jul 16 19:59:16 2013
>       NEWER than swap file!
>

That looks like a vim swap file left over from an unclean shutdown. The date suggests it is old, have you tried removing it by hand?

Does the same error occur in your other machines?