Branch merges made it hard to access change history on subversion sometimes.
You can read the tale of woe here: http://programmers.stackexchange.com/questions/206016/maintaining-svn-history-for-a-file-when-merge-is-done-from-the-dev-branch-to-tru Excerpt: "....prior to Subversion 1.8. The files in the branch and the files in trunk are copies and Subversion keeps track with svn log only for specific files, not across branches." I think that's how the custom of CHANGES.txt started, and it was cargo-culted forward into the git era despite not serving much purpose any more these days (in my opinion.) best, Colin On Mon, Mar 16, 2015 at 4:49 PM, Ravi Prakash <ravi...@ymail.com> wrote: > +1 for automating the information contained in CHANGES.txt. There are some > changes which go in without JIRAs sometimes (CVEs eg.) . I like git log > because its the absolute source of truth (cryptographically secure, audited, > distributed, yadadada). We could always use git hooks to force a commit > message format. > a) cherry-picks have the same message (by default) as the original)b) I'm not > sure why branch-mergers would be a problem?c) "Whoops I missed something in > the previous commit" wouldn't happen if our hooks were smartishd) "no > identification of what type of commit it was without hooking into JIRA > anyway." This would be in the format of the commit message > > Either way I think would be an improvement. > Thanks for your ideas folks > > > > On Monday, March 16, 2015 11:51 AM, Colin P. McCabe <cmcc...@apache.org> > wrote: > > > +1 for generating CHANGES.txt from JIRA and/or git as part of making a > release. Or just dropping it altogether. Keeping it under version > control creates lot of false conflicts whenever submitting a patch and > generally makes committing minor changes unpleasant. > > Colin > > On Sat, Mar 14, 2015 at 8:36 PM, Yongjun Zhang <yzh...@cloudera.com> wrote: >> Hi Allen, >> >> Thanks a lot for your input! >> >> Looks like problem a, c, d you listed is not too bad, assuming we can solve >> d by pulling this info from jira as Sean pointed out. >> >> Problem b (branch mergers) seems to be a real one, and your approach of >> using JIRA system to build changes.txt is a reasonably good way. This does >> count on that we update jira accurately. Since this update is a manual >> process, it's possible to have inconsistency, but may be not too bad. Since >> any mistake found here can be remedied by fixing the jira side and >> refreshing the result. >> >> I wonder if we as a community should switch to using your way, and save >> committer's effort of taking care of CHANGES.txt (quite some save IMO). >> Hope more people can share their thoughts. >> >> Thanks. >> >> --Yongjun >> >> On Fri, Mar 13, 2015 at 4:45 PM, Allen Wittenauer <a...@altiscale.com> wrote: >> >>> >>> I think the general consensus is don’t include the changes.txt file in >>> your commit. It won’t be correct for both branches if such a commit is >>> destined for both. (No, the two branches aren’t the same.) >>> >>> No, git log isn’t more accurate. The problems are: >>> >>> a) cherry picks >>> b) branch mergers >>> c) “whoops i missed something in that previous commit” >>> d) no identification of what type of commit it was without hooking into >>> JIRA anyway. >>> >>> This is why I prefer building the change log from JIRA. We already build >>> release notes from JIRA, BTW. (Not that anyone appears to read them given >>> the low quality of our notes…) Anyway, here’s what I’ve been >>> building/using as changes.txt and release notes: >>> >>> https://github.com/aw-altiscale/hadoop-release-metadata >>> >>> I try to update these every day. :) >>> >>> On Mar 13, 2015, at 4:07 PM, Yongjun Zhang <yzh...@cloudera.com> wrote: >>> >>> > Thanks Esteban, I assume this report gets info purely from the jira >>> > database, but not "git log" of a branch, right? >>> > >>> > I hope we get the info from "git log" of a release branch because that'd >>> be >>> > more accurate. >>> > >>> > --Yongjun >>> > >>> > On Fri, Mar 13, 2015 at 3:11 PM, Esteban Gutierrez <este...@cloudera.com >>> > >>> > wrote: >>> > >>> >> JIRA already provides a report: >>> >> >>> >> >>> >> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327179&styleName=Html&projectId=12310240 >>> >> >>> >> >>> >> cheers, >>> >> esteban. >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Cloudera, Inc. >>> >> >>> >> >>> >> On Fri, Mar 13, 2015 at 3:01 PM, Sean Busbey <bus...@cloudera.com> >>> wrote: >>> >> >>> >>> So long as you include the issue number, you can automate pulling the >>> >> type >>> >>> from jira directly instead of putting it in the message. >>> >>> >>> >>> On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang <yzh...@cloudera.com> >>> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I found that changing CHANGES.txt when committing a jira is error >>> prone >>> >>>> because of the different sections in the file, and sometimes we forget >>> >>>> about changing this file. >>> >>>> >>> >>>> After all, git log would indicate the history of a branch. I wonder if >>> >> we >>> >>>> could switch to a new method: >>> >>>> >>> >>>> 1. When committing, ensure the message include the type of the jira, >>> >> "New >>> >>>> Feature", "Bug Fixes", "Improvement" etc. >>> >>>> >>> >>>> 2. No longer need to make changes to CHANGES.txt for each commit >>> >>>> >>> >>>> 3. Before releasing a branch, create the CHANGES.txt by using "git >>> log" >>> >>>> command for the given branch.. >>> >>>> >>> >>>> Thanks. >>> >>>> >>> >>>> --Yongjun >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Sean >>> >>> >>> >> >>> >>> > >
