[webkit-dev] changelogs: a reprise

[David Kilzer]

On Mon, January 25, 2010 at 10:35:00 PM, Chris Jerdonek wrote:

> I was reading through the old "I HATE CHANGELOGS" messages from August:
> 
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html
> 
> The discussion attracted a lot of interest and ideas, but it looks
> like it died out without reaching any conclusion.
> 
> It seems like the tools around ChangeLogs have improved somewhat since
> then, but we still have, for example, the fundamental
> conflict-on-commit annoyance.
> 
> What do people think about these two possibilities for short- and
> mid-term strategies, respectively?
> 
> (1) Provide a simple wrapper around "svn commit" and "git svn dcommit"
> that encapsulates the retry logic in case of ChangeLog conflicts.
> This way, the end-user will never have to resolve ChangeLog conflicts
> on commit.  Higher-level commands like webkit-patch could use this
> under the hood, if they wanted, to cope with race conditions.
> 
> (2) Consider phasing in support for an alternate workflow where new
> ChangeLog entries for the next commit are stored separately from the
> versioned ChangeLog files -- perhaps in individual .changelog files
> for Subversion users and in the commit message for Git users.  The
> commands in (1) would be smart enough to read the new ChangeLog
> information from these alternate locations, and then add the ChangeLog
> information to the ChangeLog files at the last moment -- prior to
> commit.  Users of this workflow would never have to resolve ChangeLog
> conflicts during the review process, since new entries are stored
> separately.  It may be easiest to support this new workflow for Git
> users first.
> 
> The second idea is essentially Ojan's proposed modification of one of
> Maciej's ideas:
> 
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html
> 
> It is a mid-term rather than short-term strategy since it involves
> changes to several scripts (e.g. svn-create-patch) to allow the review
> process to support this alternate workflow.


I think I mentioned this before, but for git users, this can be solved in the short term by a merge driver that uses resolve-ChangeLogs (once it knows how to be invoked by git as a merge driver):

<http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers
>

I started hacking on resolve-ChangeLogs to be invoked by three arguments this way, but haven't had time to finish it.

I'm not a big fan of wrapper scripts, mostly because I'll probably forget about using them since I'm so used to using the basic git/svn commands.  (I guess svn-create-patch is a counter-argument to that, but I rarely use svn directly anymore.)

Using .changelog-bugnum files should probably be optional if it's implemented, e.g., tools should still be smart enough (or at least as smart as they are today) to operate on ChangeLog files directly if developers choose to continue doing that.  I say that because once there is a git merge driver for ChangeLog files, the need for an alternative ChangeLog workflow drops to zero, at least for me.

Dave