History is not linear - the case for micro-branching

During the Perl history conversion, I have found there are very few patches from the p5p archives which I have found I couldn’t apply. However, sometimes a pumpking will have integrated a patch which was posted relative to an older version of Perl. How am I representing that?

view of gitk on perl.git
The patch “Forbid ++ and – on readonly values” was relative to 5.003_08, and would not cleanly apply to any closer version than that. So, I made a new microbranch, applied the patch there, and included it as a parent to the perl-5.003_21 release. There is also a series of patches, “Fix for anon-lists with tied entries coredump” .. “Full documentation generation patch”. These were all successfully applied based on messages from the p5p archives. The result is a whole bunch of changes, followed by a mega-commit which is a “merge” of the loose ends. It’s also a very good representation of what really happened. You can also see little “diamonds” in the history (eg, “Re: MakeMaker and ‘make uninstall’“), where one micro-branch has the version posted to p5p, and the other the version included in the final release (if they resulted in the same thing, no diamond was formed).

With SVN, how would I do all that? Well, I’d make a new branch, pulling a name out of thin air. Apply the change on that branch, then merge back to trunk using the experimental svnmerge tool, and then delete the branch. What a PITA. Well, unless git-svnserver were to do it automatically from a git master…

Share Comments
comments powered by Disqus