On Fri, Aug 28, 2009 at 1:18 PM, Brady Eidson <[email protected]> wrote:
> On Aug 28, 2009, at 1:15 PM, David Kilzer wrote: > >> On Friday, August 28, 2009 at 1:05:57 PM, Jeremy Orlow wrote: >> >>> On Fri, Aug 28, 2009 at 12:26 PM, Brady Eidson wrote: >>> >>>> Mark Rowe already pointed out - doing an automated step for >>>> each checkin that causes another checkin would be ridiculous. >>>> But how about a nightly script that checks in a ChangeLog >>>> accounting for the day's commits? >>>> >>> >>> Agreed. If it's done daily, Trac would be a good way to look >>> at what's happened very recently. >>> >> >> This would make it impossible to track a single ChangeLog entry back to >> the original commit using git/svn annotate/blame, but the new process could >> add the commit revision to each ChangeLog entry automatically when it >> generates the update, thus achieving some level of ChangeLog-nirvana. >> > Does anyone actually have any objections to Maciej's proposal? "I can imagine a discipline where we ensure that pending commit entries sit in a designated file in your tree, are made by a tool much like prepare-ChangeLog, are included in patches by svn-create-patch, are applied by svn-apply-patch, and are used by commit-log-editor. That would ensure the entries go through the patch life cycle just as much as currently." Slightly more concrete. prepare-ChangeLog is modified to create a ".changelog" file in the root of your checkout. Then svn-create-patch, svn-apply-patch and commit-log-editor all use the .changelog file to prepend your change description to the actual ChangeLog file before doing their thing. Are there any downsides to that proposal? Ojan
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
