This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Merging lessons
- From: Rick Moseley <rmoseley at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 15 Jan 2009 13:39:29 -0600
- Subject: Merging lessons
Hi all,
I have been asked by Tom to distill some of my "lessons learned" while
doing the merges the past couple of months. Although I have learned a
lot of lessons here, I'm sure Jan has some more experience and I hope he
will add to what I have written here. Maybe we can put together some
guidelines on a wiki page when we consolidate all thoughts on this
subject. I know a lot of these are intuitive, but I feel they should be
enumerated here.
1) Make sure you start from the branch you want to merge back into;
make your branch
I had a lot of pain trying to merge modules back into branches
that seemed really out of sync with the
branch I was merging it into. This pain increases almost
exponentially as the size of the module
increases.
2) Do a rebase at least once a week
For the same reasons as no. 1, this especially is true if work is
being done on commonly modded
modules such as gdb/breakpoint.c, which is many thousands of lines.
3) We need some policy on ChangeLogs.
I haven't seen a ChangeLog merge yet that went smoothly. Using git
to "attempt" to merge
the files produces a file that is most painful to merge.
4) Do a rebase before editing configure files such as Makefile.*,
configure.*, etc. as these files are
difficult to merge.
The configure files rank right up there, IMHO, with ChangeLog as
being difficult to merge,
make sure you have the latest version before making any changes.
These are just a few thoughts I had on the merging process. Jan, I hope
you add much more to this
as you have had to master the merging of gdb code for some time now.
Any pointers/suggestions
would be most appreciated here.
Thanks,
Rick