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
(hy...@apple.com)
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
