RESOLVED FIXED Bug 107724
check-webkit-style says "Have to enable auto props in the subversion config file"
https://bugs.webkit.org/show_bug.cgi?id=107724
Summary check-webkit-style says "Have to enable auto props in the subversion config f...
Christian Biesinger
Reported 2013-01-23 13:01:52 PST
https://bugs.webkit.org/show_bug.cgi?id=9221#c5 The style review bot says I need to adjust the subversion config. Clearly, the bot should not have that message.
Attachments
Patch (8.65 KB, patch)
2013-02-20 20:58 PST, Alan Cutter
no flags
Patch (4.90 KB, patch)
2013-02-21 16:49 PST, Alan Cutter
no flags
Eric Seidel (no email)
Comment 1 2013-01-23 13:42:50 PST
I don't think this check belongs in check-webkit-style. I think it should be moved to some pre-commit check instead.
Dominik Röttsches (drott)
Comment 2 2013-01-24 04:58:48 PST
Alexey Proskuryakov
Comment 3 2013-01-24 09:51:19 PST
Can you please elaborate on the rationale? It's clear to you, but not to me. Patches include MIME type information, so what's wrong with catching mistakes early?
Eric Seidel (no email)
Comment 4 2013-01-24 12:15:34 PST
(In reply to comment #3) > Can you please elaborate on the rationale? It's clear to you, but not to me. > > Patches include MIME type information, so what's wrong with catching mistakes early? Oh, the problem is this is check-webkit-style yelling about a configuration issue, on the machine. It's OK for us to do that on users's machines, but it doesn't make much sense on the bot. I'm not certain that git patches do include mimetype info? Or at least it's not clear to me why some people's patches go crazy and others don't. The CQ should be configured to land these types of files with the right mime-types anyway, so only manual land users should run into this.
Alexey Proskuryakov
Comment 5 2013-01-24 12:23:56 PST
> Oh, the problem is this is check-webkit-style yelling about a configuration issue, on the machine. It's OK for us to do that on users's machines, but it doesn't make much sense on the bot. I see. So it's the phrasing of the complaint that is the issue - it should say that MIME type is wrong in the patch, and possibly suggest using auto-props. Obviously, the tool has no crystal ball to tell what's happening at user's machine - they may as well have auto-props, but manually remove MIME types from patches before submitting them :).
Christian Biesinger
Comment 6 2013-01-24 12:31:23 PST
That's not what the check is doing though. It literally checks the subversion config file, not the patch. See Tools/Scripts/webkitpy/common/checksvnconfigfile.py as used by Tools/Scripts/webkitpy/style/checkers/png.py
Alexey Proskuryakov
Comment 7 2013-01-24 13:15:40 PST
Oh. That makes no sense to me either.
Alan Cutter
Comment 8 2013-01-24 16:34:04 PST
I have updated the .subversion/config file on gce-feeder-01 (where the style queue lives currently). I agree it does seem strange for the style checker to be checking its own machine instead of the patch directly but I have no qualms against simply making sure the bots are set up correctly.
Alexey Proskuryakov
Comment 9 2013-01-24 22:28:36 PST
*** Bug 107862 has been marked as a duplicate of this bug. ***
Christian Biesinger
Comment 10 2013-02-19 15:05:46 PST
*** Bug 110249 has been marked as a duplicate of this bug. ***
Christian Biesinger
Comment 11 2013-02-19 15:06:33 PST
Alan, looks like this is happening again: https://bugs.webkit.org/show_bug.cgi?id=109994#c6
Alan Cutter
Comment 12 2013-02-20 20:58:57 PST
Alan Cutter
Comment 13 2013-02-20 21:01:06 PST
(In reply to comment #11) > Alan, looks like this is happening again: https://bugs.webkit.org/show_bug.cgi?id=109994#c6 Thanks for notifying me. Fixed up the subversion config file on gce-feeder-01 again. (In reply to comment #12) > Created an attachment (id=189454) [details] > Patch Submitting patch to resolve issue.
Eric Seidel (no email)
Comment 14 2013-02-20 22:50:53 PST
Why all the boiler-plate? Should we just have a standard svn-config which we recommend for the project?
Alan Cutter
Comment 15 2013-02-20 23:34:38 PST
(In reply to comment #14) > Why all the boiler-plate? > > Should we just have a standard svn-config which we recommend for the project? A standard svn config file sound like a good idea, I'm not familiar with WebKit's directory structure enough to decide where to put it. By boilerplate do you mean all the comments that come with the config file? I decided to leave them in as I can only see them being useful when doing EWS bot maintenance. As an alternative to storing the svn config file in the repo for developers I think adding instructions for enabling the particular SVN flags on the WebKit wiki could be sufficient. https://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree Possibly adding a section under Pixel test tips.
Eric Seidel (no email)
Comment 16 2013-02-21 00:49:00 PST
Comment on attachment 189454 [details] Patch No, I think we definitely want a standard recommended config file in the repo. I just think the boiler-plate is a bit silly. :) This is just a two-line file, no? Seems we also want .sln files, etc, no?
Eric Seidel (no email)
Comment 17 2013-02-21 00:49:28 PST
CCing folks who may have an opinion about a standard svnconfig file for WebKit.
Tony Chang
Comment 18 2013-02-21 11:34:29 PST
vcproj, sln and vsprops files should be svn:eol-style native. See bug 96934 for a discussion of this. Checking in a config file and having the style check suggest using it seems fine to me. Not sure it's worthwhile to keep all the commented out lines in the same config file. It seems like it was good that this check was run on the bots, otherwise we wouldn't have known to fix the bots.
Alan Cutter
Comment 19 2013-02-21 14:53:40 PST
If we include a svn config file in the repo should we also include a script to merge it with the user's existing svn repo? This might be a bit invasive. Perhaps documentation on the Wiki is suitable enough. In terms of where the svn config file should go does Tools/config/svn-config sound appropriate? As far as I can tell there's no other directory for user config files.
Alan Cutter
Comment 20 2013-02-21 14:59:10 PST
(In reply to comment #19) > If we include a svn config file in the repo should we also include a script to merge it with the user's existing svn repo? *user's existing svn config
Eric Seidel (no email)
Comment 21 2013-02-21 15:00:45 PST
I suspect most users don't have a config to start with. They probably have one for WebKit, because it's needed for the silly png thing, but having a cannonical config to recommend when setting up new machines is the right long-term solution IMO.
Tony Chang
Comment 22 2013-02-21 15:30:01 PST
(In reply to comment #19) > If we include a svn config file in the repo should we also include a script to merge it with the user's existing svn repo? This might be a bit invasive. Perhaps documentation on the Wiki is suitable enough. Seems like overkill. I think it's reasonable to do just check that the settings are correct and if they're incorrect, point the user to a wiki page or tell them how to fix. > In terms of where the svn config file should go does Tools/config/svn-config sound appropriate? > As far as I can tell there's no other directory for user config files. I would probably put it at Tools/svn-config (or Tools/subversion-config) to avoid making a subdirectory with 1 file in it.
Alan Cutter
Comment 23 2013-02-21 16:49:44 PST
Alan Cutter
Comment 24 2013-02-21 16:51:55 PST
(In reply to comment #23) > Created an attachment (id=189639) [details] > Patch Removed comments in svn-config file. Placed svn-config under Tools/ Added *.sln = svn:eol-style=native *.vcproj = svn:eol-style=native *.vsprops = svn:eol-style=native to svn-config. Updated bot scripts to use new location.
Tony Chang
Comment 25 2013-02-21 17:01:27 PST
Comment on attachment 189639 [details] Patch LGTM. I don't feel strongly about the location of the file, but someone else might.
WebKit Review Bot
Comment 26 2013-03-04 21:26:15 PST
Comment on attachment 189639 [details] Patch Clearing flags on attachment: 189639 Committed r144716: <http://trac.webkit.org/changeset/144716>
WebKit Review Bot
Comment 27 2013-03-04 21:26:21 PST
All reviewed patches have been landed. Closing bug.
Viatcheslav Ostapenko
Comment 28 2013-03-11 23:14:34 PDT
(In reply to comment #8) > I have updated the .subversion/config file on gce-feeder-01 (where the style queue lives currently). > > I agree it does seem strange for the style checker to be checking its own machine instead of the patch directly but I have no qualms against simply making sure the bots are set up correctly. Still style check fails for pngs on EWS bot. Thought that git doesn't add mime type info and created patch in svn tree and checked that mime type is included, but it didn't help. Here: https://bugs.webkit.org/show_bug.cgi?id=110620
Alan Cutter
Comment 29 2013-03-11 23:41:55 PDT
(In reply to comment #28) > (In reply to comment #8) > > I have updated the .subversion/config file on gce-feeder-01 (where the style queue lives currently). > > > > I agree it does seem strange for the style checker to be checking its own machine instead of the patch directly but I have no qualms against simply making sure the bots are set up correctly. > > Still style check fails for pngs on EWS bot. > Thought that git doesn't add mime type info and created patch in svn tree and checked that mime type is included, but it didn't help. > Here: https://bugs.webkit.org/show_bug.cgi?id=110620 Thanks for reporting this. I'm positive the config was updated on the style bot but upon checking it was back to the default. I've updated it again to the required settings. Please try your patch again, apologies for the inconvenience!
Note You need to log in before you can comment on or make changes to this bug.