[webkit-dev] I *HATE* CHANGELOGS!!!

[David Hyatt]

On Aug 26, 2009, at 3:43 PM, Maciej Stachowiak wrote:

>
> On Aug 26, 2009, at 3:37 PM, David Hyatt wrote:
>
>> If the files could just merge properly, I would not be so annoyed,  
>> but the fact that you basically have to re-resolve conflicts every  
>> time anyone beats you to a checkin is just horrible.  Surely other  
>> people run into this.  It wastes time for me on practically every  
>> single checkin.... and I have ended up causing regressions because  
>> I don't wait to re-run layout tests every time just because I am  
>> trying to get my files landed before someone else modified the  
>> ChangeLog again.
>
> If you use update-webkit it should merge the ChangeLog for you, or  
> if you use vanilla svn update, resolve-ChangeLogs should fix up the  
> conflicts. Do these not work for you?
>

No, they really don't.

update-webkit is very heavyweight when you are mostly working in one  
particular area.  I don't necessarily want to rebuild the whole world  
just because I wrote a 2-line patch to one file in WebCore.  I don't  
need to test how that patch interacts with every other new change made  
since I last wrote the patch, so telling me I have to fully update to  
ToT is lame.

Remember also that update-webkit pulls the internal Safari tree for  
Apple folks as well, so that makes it even more heavyweight.  I  
certainly don't need all the random Safari UI changes for the day just  
because I want to land a WebCore patch.

So assuming I don't update-webkit every single time I want to write a  
ChangeLog, I end up having to run resolve-Changelogs myself.

The other annoyance is that I have essentially a single checkin  
comment that I have to duplicate across N changelogs.  Even the most  
minimal patch forces me to touch two ChangeLogs and say the exact same  
thing in both.  This is a pain.  Some WebKit refactoring changes I've  
made in the past have forced me to touch as many as SEVEN(!!!)  
ChangeLogs just to check in.  This is just nuts.

On top of that, resolve-Changelogs often fails on the LayoutTests  
changelog, and you have to svn resolve manually.  Even before you get  
to the conflict state, ChangeLogs can merge "cleanly" forcing you to  
then hand edit them to move your entry up to the top of the file.

I've literally had situations where I get conflicts worked out, make  
the 2-3 changes a reviewer demands, run layout tests, and then someone  
else beats me to a checkin.  I don't necessarily want to pull that  
person's checkin just to land (maybe they touched Vector.h or  
something).  I just want to get my patch in.  A model where I am  
forced to keep re-syncing up to a rapidly changing ToT is not a good  
one, especially when I know my change is simple and self-contained.

>>
>> On top of that sometimes the ChangeLog merges cleanly but puts your  
>> entry underneath others, and then you have to open the file and  
>> move your entry back to the top.  Sometimes I have not noticed this  
>> and then I land with someone else's commit message.
>>
>> I just don't get why people are willing to put up with this.  It's  
>> really driving me crazy.
>
> The above make it tolerable for me, but if it's really unlivable, we  
> can consider some other way to do this. One possibility is to have a  
> commit hook that builds the ChangeLog entry and includes it in the  
> commit atomically - that way there are no races.
>

I really consider it intolerable.  This has been bugging me for a long  
time, and hearing others complain about it (and running into it yet  
again) has motivated me to say something. :)

Having to edit seven changelogs to put the same message in each just  
to be able to land a patch is stupid.

dave
(hyatt at apple.com)