We'd then doing two commits for every patch. Let's simply not remove CHANGES.txt from trunk, keep the existing dev workflow, but doc the release process to remove CHANGES.txt in trunk at the time of a release going out of trunk.
+Vinod On Apr 2, 2015, at 10:12 AM, Allen Wittenauer <a...@altiscale.com<mailto:a...@altiscale.com>> wrote: But in reality, I suspect the opposite: removing changes.txt just from trunk will make cherry picks easier. If you don’t have to update trunk’s changes.txt, you can cherry-pick with no worries about conflict merges on changes.txt in other branches. Then just update changes.txt in branch-2 manually as you would have done pre- this change anyway.
