[mapserver-dev] Re: applying bugfixes to multiple branches

[thomas bonfort]

I've started a wiki page with some good practices. Please feel free to
add or ammend:

https://github.com/mapserver/mapserver/wiki/WorkingWithGit

Steve pointed out that this workflow for release branches will
consistently provoke a merge conflict on our HISTORY.TXT file, as this
file diverges in each release branch. Although fixing this conflict is
pretty simple (cut the conflicting line and paste it at the beginning
of the changes for the current release), it would be nice to start
thinking on how we can rely on commit logs for generating a release
history rather than maintaining this file.
One solution would be to add a special tag in the commit message that
we can grep through when creating the release notes. There are two
kind of messages that must be highlighted:

- fixes to the stable branches: every single bugfix to the repo should
contain a commit with this tag.
- changes to master: a tag would be added for commits/pushes that add
a new feature or a change worthy of appearing in the release notes.

the syntax used for these tags could be ==rel== and ==tag== , e.g.:

==rel== fix divide by 0 in mapfoo.c (#1234)
or
==tag== add support for SVG symbols (rfc99)

thoughts?

--
thomas

On Wed, Apr 4, 2012 at 19:57, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> Btw,
> This proposed change isn't mandatory, we can quit using it if we find
> out it's too cumbersome in the long run. I do think we should give it
> a try as there are many times we only fix in trunk whereas fixing in
> the previous release branch could be just as easy with this method.
> The "downside" is that until we decide wether we want to keep working
> this way, all changes to stable branches should be done this way.
>
> --
> thomas
>
> On Wed, Apr 4, 2012 at 19:34, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> Hi devs,
>> Following the workflow described here
>> http://www.net-snmp.org/wiki/index.php/Git_Workflow,
>> I've setup a script in our repository that changes the way fixes
>> should be applied to stable branches. The aim is to simplify the task
>> of applying a fix to multiple branches. So, in the case where a fix
>> needs to be applied to more than just master, this is the workflow to
>> use:
>>
>> - make sure you have an uptodate clone, and that your master and
>> stable branches don't have any uncommited or unpushed changes
>>
>> - pick the oldest branch your fix applies to (or that you are willing
>> to support), for the example let's say it is branch-5-4
>>
>> - set your working copy to this branch:
>>  git checkout branch-5-4
>>
>> - create a temporary branch for your fix
>>  git checkout -b bug1234
>>
>> - code, test your fix, etc...
>>  git add changd_file.c
>>  git commit -m "fix bug 1234, blabla"
>>
>> - once the fix is ready merge it into branch-5-4
>>  git checkout branch-5-4
>>  git merge bug1234
>>
>> - you are now ready to apply this fix in the newer release branches. A
>> script automates this process:
>>  sh stablemerge.sh
>>
>> - what the script does is iteratively merge 4-10 into 5-0, then 5-0
>> into 5-2, etc, up till 6-0 into master. This means your fix is
>> propagated to all newer branches down into master.
>>
>> - for more complex fixes and/or very old branches, the fix will likely
>> not always apply cleanly from one branch to the next. You'll be
>> returned back to your shell with a message indicating which file has a
>> conflict and asked to manually edit it to resolve. Once you've fixed
>> the conflict, commit your edited file, and rerun the stablemerge.sh
>> script to continue propagating your updated fix to newer branches.
>>
>> Please try to avoid copy-pasting a fix in multiple branches to
>> accomplish the same task, as it will result in conflicts the next time
>> someone runs the process.
>>
>> Don't hesitate to ping me if you need help with this.
>>
>> best regards,
>>
>> thomas