the great branching experiment..

> Since pushing out 1.59.2 this morning I've done two more things:
>
>  1. added support for a 'create branch' command
>  2. turned all tests green (using expectedFailures, so I cheated just a tiny bit)
>
> ConfigurationOfMetacelloBrowser-dkh.305 is currently the head of the trunk and from this point  on (as long as the experiment lasts:) let's do development and bugfixes on branches. Periodically I will integrate the changes into the trunk.
>
> The point of the experiment is to see if it is possible to build up the tool set to make branching and merging painless ...
>
> Pushing out 1.59.2 which involved some cherry picking from Alex's checkins and then merging the changes made along the 1.59.2 branch into 1.60 and it wasn't that difficult to do, so I'm imaging that we have a solvable problem, but I'd like to get some actual experience doing it and that takes some help from other folks ...
>
> For example, Tobias supplied suggested bugfixes for Issue133 and Issue 132. In the great experiment I would like to see the same type of bug reports, but instead of changesets of inline code, include a referece to a branch containing the proposed fix.
>
> So if a bug is found in 1.59.2 (say Issue 135), I think that it would make sense for the person fixing the bug (or suggesting a fix) to start with the head of the trunk (ConfigurationOfMetacelloBrowser-dkh.305 right now), load 1.60, then create a branch named 'Issue135' (mark the issue as started), then load 1.59.2, set it as the #development symbolic version and make the fix, by doing a final 'checkpoint dev' of MetacelloBrowser.Issue135 and including a reference to the committed configuration (say ConfigurationOfMetacelloBrowser.Issue135-dkh.306) in the bug report and mark it fixed ...when I integrate the fix into the trunk, I'll close the bug ... once the bugfix is completed no further developmetn should be done on the Issue135 branch ...
>
> I already know that there are handful of manual operations that will be done just to accomplish the above steps, so part of the great experiment is to identify those manual steps, report them as an issue.
>
> Then someone else (or the person who reported the bug) can come along, and address the issue from another branch...
>
> I would like tests submitted and all of the tests green, but at this point in time I am more interested in the experiment and if you can take an hour and take a shot a bug, a new feature, or improving an existing feature  I don't want to discourage folks from participating
>
> Ultimately tests will need to be written and turned green, but that can be done on a branch as well ...
>
> I've created a branch of my own 'dkh_1_60' where I will be working on finishing up the work that I have ongoing there.
>
> I'm hoping that a number of folks will decide to contribute to the experiment so that we can find out if it can work in the real world ... so if you don't have a lot of time, just create a branch and improve the wording in the #document of a command or improve the help a little bit ... then submit  a bug report with details ... and of course submit bug reports for problems that you run into ... and I invite you to try out experiments in integration and merging on your own to see what the problems are and to see if you have suggestions for improvements ...
>
> It's an experiment so let's not be shy about experimenting:)
>
> Dale
>

> Arg... I do not have a bug to fixed, but I just pressed 'create branch' to try it out. It saved the configuration under a new name and I did not know this will be saved. Shall I remove "MetacelloBrowser.branchBugFix" from the ssource rep ?
>
> Alexandre
>
>
>
> On 17 Apr 2011, at 19:47, Dale Henrichs wrote:
>
>> Since pushing out 1.59.2 this morning I've done two more things:
>>
>> 1. added support for a 'create branch' command
>> 2. turned all tests green (using expectedFailures, so I cheated just a tiny bit)
>>
>> ConfigurationOfMetacelloBrowser-dkh.305 is currently the head of the trunk and from this point  on (as long as the experiment lasts:) let's do development and bugfixes on branches. Periodically I will integrate the changes into the trunk.
>>
>> The point of the experiment is to see if it is possible to build up the tool set to make branching and merging painless ...
>>
>> Pushing out 1.59.2 which involved some cherry picking from Alex's checkins and then merging the changes made along the 1.59.2 branch into 1.60 and it wasn't that difficult to do, so I'm imaging that we have a solvable problem, but I'd like to get some actual experience doing it and that takes some help from other folks ...
>>
>> For example, Tobias supplied suggested bugfixes for Issue133 and Issue 132. In the great experiment I would like to see the same type of bug reports, but instead of changesets of inline code, include a referece to a branch containing the proposed fix.
>>
>> So if a bug is found in 1.59.2 (say Issue 135), I think that it would make sense for the person fixing the bug (or suggesting a fix) to start with the head of the trunk (ConfigurationOfMetacelloBrowser-dkh.305 right now), load 1.60, then create a branch named 'Issue135' (mark the issue as started), then load 1.59.2, set it as the #development symbolic version and make the fix, by doing a final 'checkpoint dev' of MetacelloBrowser.Issue135 and including a reference to the committed configuration (say ConfigurationOfMetacelloBrowser.Issue135-dkh.306) in the bug report and mark it fixed ...when I integrate the fix into the trunk, I'll close the bug ... once the bugfix is completed no further developmetn should be done on the Issue135 branch ...
>>
>> I already know that there are handful of manual operations that will be done just to accomplish the above steps, so part of the great experiment is to identify those manual steps, report them as an issue.
>>
>> Then someone else (or the person who reported the bug) can come along, and address the issue from another branch...
>>
>> I would like tests submitted and all of the tests green, but at this point in time I am more interested in the experiment and if you can take an hour and take a shot a bug, a new feature, or improving an existing feature  I don't want to discourage folks from participating
>>
>> Ultimately tests will need to be written and turned green, but that can be done on a branch as well ...
>>
>> I've created a branch of my own 'dkh_1_60' where I will be working on finishing up the work that I have ongoing there.
>>
>> I'm hoping that a number of folks will decide to contribute to the experiment so that we can find out if it can work in the real world ... so if you don't have a lot of time, just create a branch and improve the wording in the #document of a command or improve the help a little bit ... then submit  a bug report with details ... and of course submit bug reports for problems that you run into ... and I invite you to try out experiments in integration and merging on your own to see what the problems are and to see if you have suggestions for improvements ...
>>
>> It's an experiment so let's not be shy about experimenting:)
>>
>> Dale
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> Yeah, go ahead a delete the junk...
>
> Dale
>
> On Apr 18, 2011, at 5:56 AM, Alexandre Bergel wrote:
>
>> Arg... I do not have a bug to fixed, but I just pressed 'create branch' to try it out. It saved the configuration under a new name and I did not know this will be saved. Shall I remove "MetacelloBrowser.branchBugFix" from the ssource rep ?
>>
>> Alexandre
>>
>>
>>
>> On 17 Apr 2011, at 19:47, Dale Henrichs wrote:
>>
>>> Since pushing out 1.59.2 this morning I've done two more things:
>>>
>>> 1. added support for a 'create branch' command
>>> 2. turned all tests green (using expectedFailures, so I cheated just a tiny bit)
>>>
>>> ConfigurationOfMetacelloBrowser-dkh.305 is currently the head of the trunk and from this point  on (as long as the experiment lasts:) let's do development and bugfixes on branches. Periodically I will integrate the changes into the trunk.
>>>
>>> The point of the experiment is to see if it is possible to build up the tool set to make branching and merging painless ...
>>>
>>> Pushing out 1.59.2 which involved some cherry picking from Alex's checkins and then merging the changes made along the 1.59.2 branch into 1.60 and it wasn't that difficult to do, so I'm imaging that we have a solvable problem, but I'd like to get some actual experience doing it and that takes some help from other folks ...
>>>
>>> For example, Tobias supplied suggested bugfixes for Issue133 and Issue 132. In the great experiment I would like to see the same type of bug reports, but instead of changesets of inline code, include a referece to a branch containing the proposed fix.
>>>
>>> So if a bug is found in 1.59.2 (say Issue 135), I think that it would make sense for the person fixing the bug (or suggesting a fix) to start with the head of the trunk (ConfigurationOfMetacelloBrowser-dkh.305 right now), load 1.60, then create a branch named 'Issue135' (mark the issue as started), then load 1.59.2, set it as the #development symbolic version and make the fix, by doing a final 'checkpoint dev' of MetacelloBrowser.Issue135 and including a reference to the committed configuration (say ConfigurationOfMetacelloBrowser.Issue135-dkh.306) in the bug report and mark it fixed ...when I integrate the fix into the trunk, I'll close the bug ... once the bugfix is completed no further developmetn should be done on the Issue135 branch ...
>>>
>>> I already know that there are handful of manual operations that will be done just to accomplish the above steps, so part of the great experiment is to identify those manual steps, report them as an issue.
>>>
>>> Then someone else (or the person who reported the bug) can come along, and address the issue from another branch...
>>>
>>> I would like tests submitted and all of the tests green, but at this point in time I am more interested in the experiment and if you can take an hour and take a shot a bug, a new feature, or improving an existing feature  I don't want to discourage folks from participating
>>>
>>> Ultimately tests will need to be written and turned green, but that can be done on a branch as well ...
>>>
>>> I've created a branch of my own 'dkh_1_60' where I will be working on finishing up the work that I have ongoing there.
>>>
>>> I'm hoping that a number of folks will decide to contribute to the experiment so that we can find out if it can work in the real world ... so if you don't have a lot of time, just create a branch and improve the wording in the #document of a command or improve the help a little bit ... then submit  a bug report with details ... and of course submit bug reports for problems that you run into ... and I invite you to try out experiments in integration and merging on your own to see what the problems are and to see if you have suggestions for improvements ...
>>>
>>> It's an experiment so let's not be shy about experimenting:)
>>>
>>> Dale
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>