Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.First noticed by Morbus and mentioned on IRC.
Here's an example:
http://drupal.org/cvs?commit=50633
When doing a commit that involves more than one file, the commit log message repeats the first commited file rather than a line for each file committed. Make sense? See example taken from above URL:-
January 10, 2007
Commit #50633 by Dries
Drupal: /modules/user/user.module 1.742
Drupal: /modules/user/user.module 1.742
Drupal: /modules/user/user.module 1.742
Drupal: /modules/user/user.module 1.742
Drupal: /modules/user/user.module 1.742
Drupal: /modules/user/user.module 1.742
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | xcvs-loginfo-duplicate-entries.patch.txt | 999 bytes | dww |
Comments
Comment #1
dwwcrap, this is bad, since things are actually wrong in the DB. so, the problem here is that something went wrong with the xcvs-* scripts that notice the commit and stuff the info into the DB. :( ugh. and, obviously, it's intermitent, not a regular bug, which will make this much harder to reproduce, locate and fix. could be anything from bad corner-case logic in the scripts, to intermittent DB failures between cvs.d.o and drupaldb.d.o, to php config errors on cvs.d.o, etc.
one thing i've noticed before, but haven't had time to do anything about, is that the xcvs-* scripts do *NOT* check return values when trying to update the DB. so, a simple and good first step might be to just go through all that code, see where it's talking to the DB, and at least report errors. better yet, retry as reasonable and only fail if we give up after N tries or something.
i have no time for this bug today, and possibly not even this week, so if anyone else is inspired to pick up the torch, please reply and assign this to yourself.
thanks,
-derek
Comment #2
AjK commentedIt doesn't look like a "corner case". Just look at the CVS log messages page and every "multi file commit" is broken.
I'll try haveing a look (xcvs-loginfo.php I guess) and see what's going on.
Comment #3
AjK commentedJust for the record, this commit http://drupal.org/cvs?commit=50456 appears to be the first example of a multi-file commit the displays the error. It at least gives us an "approximate point in time" when this start:
Comment #4
dwwcrap, yeah, than it's probably php and/or cvs configuration changes on cvs.d.o that are to blame. :( that's right around the time there was stuff happening on that host, software updates, etc...
Comment #5
AjK commentedAgreed. I don't think this is a D5 issue. Dries post about eating our own dog food was at 16hrs 7 Jan but this error started more than 24hrs later at close to midnight 8th Jan. If I remember correctly, wasn't this around the time PHP was re-compiled for cvs.drupal.org ? Could that be to blame? I can't quite see how, sounds more like a CVS config change. So many changes so close together in time!
Comment #6
dwwyee haw! i found it. i guess the old php version allowed the buggy code to work, whereas the new version was barfing on this. we were reusing an object in a loop, instead of making a new one each time. a simple:
$cvslog_file = new stdClass();in the right place is all we need. while i was at it, i cleaned up some usage of
$GLOBALSthat seemed needlessly complicated for a more simpleglobal $foo...Comment #7
dwwcommitted to HEAD, DRUPAL-4-7--2 and DRUPAL-4-7. installed on d.o and s.d.o.
see http://drupal.org/node/108441 for the d.o infra task about repairing the now broken {cvs_files} table...
Comment #8
(not verified) commented