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

[Stephan Meißl]

Thomas, all,

finally I started enjoying git and github :) and I hope I used it the
right way. Thanks for the detailed instructions.

After going through it I agree that we should think of an alternative to
the HISTORY.TXT and the proposed solution looks good to me.

One question to github: Adding an issue I was wondering if there
shouldn't be milestones 6.0.3, 5.6.9, etc. under "Open" and I guess
6.0.2, etc. should go under "Closed"?

cu
Stephan


On Wed, 2012-04-04 at 22:01 +0200, thomas bonfort wrote:
> 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
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev