Re: [webkit-dev] Microdata document.getItems()
I tried to run the mentioned test cases in my local machine, its working fine. I have tested the same in latest Webkit revision (Chromium/GTK port). Not sure what could be the issue. Can you please attach the test failure diff here? Thanks and regards, Arko On Thu, Mar 8, 2012 at 1:29 PM, Gurpreet Kaur gur.t...@gmail.com wrote: Dear Ryosuke, Thanks for the update. Dear Arko, Could you please help me with this? Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Your best bet is to talk with Arko :) - Ryosuke On Wed, Mar 7, 2012 at 11:26 PM, Gurpreet Kaur gur.t...@gmail.comwrote: Dear Webkit Team, I am working on Microdata for Android browser. After taking all the changes related to Microdata the following test case is failing for me. http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html This test case has call to document.getItems() (with no arguments). The call with arguments is working fine. Please update incase anyone have enabled the Microdata and tested these layout test cases. Thanks and Regards, Gurpreet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Microdata document.getItems()
Hi Arko, On running the test case http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html I get the result as below. This test ensures that document.getItems().length must return the correct number of MicroData Items in the Document. Also it tests that document.getItems must return a live NodeList. *FAIL - expected 4 elements but got 0 elements.* document.getItems() with empty string in the aurgument : PASS document.getItems() with 'http://example.com/foo' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/bar' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/f1' itemtype in the aurgument : PASS Created element of type : div Set attribute: itemscope, value: itemscope *FAIL - expected 5 elements but got 0 elements.* *FAIL - expected 4 elements but got 0 elements.* document.getItems() should return all items and document.getItems(arg) should return items which match the arg. Please correct me if I am wrong. Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:36 PM, Arko Saha ngh...@motorola.com wrote: I tried to run the mentioned test cases in my local machine, its working fine. I have tested the same in latest Webkit revision (Chromium/GTK port). Not sure what could be the issue. Can you please attach the test failure diff here? Thanks and regards, Arko On Thu, Mar 8, 2012 at 1:29 PM, Gurpreet Kaur gur.t...@gmail.com wrote: Dear Ryosuke, Thanks for the update. Dear Arko, Could you please help me with this? Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Your best bet is to talk with Arko :) - Ryosuke On Wed, Mar 7, 2012 at 11:26 PM, Gurpreet Kaur gur.t...@gmail.comwrote: Dear Webkit Team, I am working on Microdata for Android browser. After taking all the changes related to Microdata the following test case is failing for me. http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html This test case has call to document.getItems() (with no arguments). The call with arguments is working fine. Please update incase anyone have enabled the Microdata and tested these layout test cases. Thanks and Regards, Gurpreet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Microdata document.getItems()
Hi Gurpreet, Yes, document.getItems() takes an optional string types as the argument. It should return all microdata items in the document if the types argument is missing. I could see its working as expected in todays revision. Are you using latest Webkit revision?? If you are just merging microdata patches on some old webkit revision then I cannot help. In older revisions please check the implementation of a existing method which allows optional argument. Thanks and Regards, Arko On Thu, Mar 8, 2012 at 1:49 PM, Gurpreet Kaur gur.t...@gmail.com wrote: Hi Arko, On running the test case http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html I get the result as below. This test ensures that document.getItems().length must return the correct number of MicroData Items in the Document. Also it tests that document.getItems must return a live NodeList. *FAIL - expected 4 elements but got 0 elements.* document.getItems() with empty string in the aurgument : PASS document.getItems() with 'http://example.com/foo' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/bar' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/f1' itemtype in the aurgument : PASS Created element of type : div Set attribute: itemscope, value: itemscope *FAIL - expected 5 elements but got 0 elements.* *FAIL - expected 4 elements but got 0 elements.* document.getItems() should return all items and document.getItems(arg) should return items which match the arg. Please correct me if I am wrong. Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:36 PM, Arko Saha ngh...@motorola.com wrote: I tried to run the mentioned test cases in my local machine, its working fine. I have tested the same in latest Webkit revision (Chromium/GTK port). Not sure what could be the issue. Can you please attach the test failure diff here? Thanks and regards, Arko On Thu, Mar 8, 2012 at 1:29 PM, Gurpreet Kaur gur.t...@gmail.com wrote: Dear Ryosuke, Thanks for the update. Dear Arko, Could you please help me with this? Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Your best bet is to talk with Arko :) - Ryosuke On Wed, Mar 7, 2012 at 11:26 PM, Gurpreet Kaur gur.t...@gmail.comwrote: Dear Webkit Team, I am working on Microdata for Android browser. After taking all the changes related to Microdata the following test case is failing for me. http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html This test case has call to document.getItems() (with no arguments). The call with arguments is working fine. Please update incase anyone have enabled the Microdata and tested these layout test cases. Thanks and Regards, Gurpreet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Microdata document.getItems()
Hi Arko, Yes I am using older webkit version and have just merged the Microdata patch. When I try to do alert(document.getItems()) via script I get Object NodeList but .lenght returns 0. If possible Can you just explain how is the length calculated? Regards, Gurpreet On Thu, Mar 8, 2012 at 2:20 PM, Arko Saha ngh...@motorola.com wrote: Hi Gurpreet, Yes, document.getItems() takes an optional string types as the argument. It should return all microdata items in the document if the types argument is missing. I could see its working as expected in todays revision. Are you using latest Webkit revision?? If you are just merging microdata patches on some old webkit revision then I cannot help. In older revisions please check the implementation of a existing method which allows optional argument. Thanks and Regards, Arko On Thu, Mar 8, 2012 at 1:49 PM, Gurpreet Kaur gur.t...@gmail.com wrote: Hi Arko, On running the test case http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html I get the result as below. This test ensures that document.getItems().length must return the correct number of MicroData Items in the Document. Also it tests that document.getItems must return a live NodeList. *FAIL - expected 4 elements but got 0 elements.* document.getItems() with empty string in the aurgument : PASS document.getItems() with 'http://example.com/foo' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/bar' itemtype in the aurgument : PASS document.getItems() with 'http://example.com/f1' itemtype in the aurgument : PASS Created element of type : div Set attribute: itemscope, value: itemscope *FAIL - expected 5 elements but got 0 elements.* *FAIL - expected 4 elements but got 0 elements.* document.getItems() should return all items and document.getItems(arg) should return items which match the arg. Please correct me if I am wrong. Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:36 PM, Arko Saha ngh...@motorola.com wrote: I tried to run the mentioned test cases in my local machine, its working fine. I have tested the same in latest Webkit revision (Chromium/GTK port). Not sure what could be the issue. Can you please attach the test failure diff here? Thanks and regards, Arko On Thu, Mar 8, 2012 at 1:29 PM, Gurpreet Kaur gur.t...@gmail.comwrote: Dear Ryosuke, Thanks for the update. Dear Arko, Could you please help me with this? Thanks and Regards, Gurpreet On Thu, Mar 8, 2012 at 1:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Your best bet is to talk with Arko :) - Ryosuke On Wed, Mar 7, 2012 at 11:26 PM, Gurpreet Kaur gur.t...@gmail.comwrote: Dear Webkit Team, I am working on Microdata for Android browser. After taking all the changes related to Microdata the following test case is failing for me. http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/MicroData/002.html This test case has call to document.getItems() (with no arguments). The call with arguments is working fine. Please update incase anyone have enabled the Microdata and tested these layout test cases. Thanks and Regards, Gurpreet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Microdata document.getItems()
On Thu, Mar 8, 2012 at 12:57 AM, Gurpreet Kaur gur.t...@gmail.com wrote: Yes I am using older webkit version and have just merged the Microdata patch. When I try to do alert(document.getItems()) via script I get Object NodeList but .lenght returns 0. That's not a good idea. There have been a number of recent changes to the way DynamicNodeList/HTMLCollection works. In particular, I remember Arko and I fixed a number of bugs in other parts of WebKit to make microdata API work. I highly recommend that you use a newer revision of WebKit that has microdata API instead of using an older revision and manually merging changes. If possible Can you just explain how is the length calculated? Look at definitions of those two classes. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS3 Paged Media module
2012/3/8, David Hyatt hy...@apple.com: That page should be updated. We don't have that architectural flaw any longer since I re-wrote pagination last year. Please do so! -- Seo Sanghyeon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash From: Simon Fraser simon.fra...@apple.com To: Eric Seidel e...@webkit.org Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 3:37 AM Subject: Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Microdata document.getItems()
Dear Ryosuke/Arko. Thanks for the support and the quick response. Regards, Gurpreet On Thu, Mar 8, 2012 at 2:50 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 12:57 AM, Gurpreet Kaur gur.t...@gmail.com wrote: Yes I am using older webkit version and have just merged the Microdata patch. When I try to do alert(document.getItems()) via script I get Object NodeList but .lenght returns 0. That's not a good idea. There have been a number of recent changes to the way DynamicNodeList/HTMLCollection works. In particular, I remember Arko and I fixed a number of bugs in other parts of WebKit to make microdata API work. I highly recommend that you use a newer revision of WebKit that has microdata API instead of using an older revision and manually merging changes. If possible Can you just explain how is the length calculated? Look at definitions of those two classes. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving to Git?
WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. [1] https://bugs.webkit.org/show_bug.cgi?id=79509#c6 [2] http://trac.webkit.org/wiki/Moving%20to%20Git [3] http://trac.webkit.org/wiki/Moving%20to%20Git?action=history Thanks for lending an ear, -Ash___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
En 08/03/12 13:35, Ashod Nakashian escribiu: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not. Anyway I'd be really pleased if that move happens. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 7:46 AM, Sergio Villar Senin svil...@igalia.comwrote: En 08/03/12 13:35, Ashod Nakashian escribiu: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not. A version of git ships with Xcode, and without Xcode I don't think anyone attempting to hack on WebKit will get very far :3 Anyway I'd be really pleased if that move happens. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
I personally use either git or git-svn and would welcome the move. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ashod Nakashian [ashodnakash...@yahoo.com] Sent: Thursday, March 08, 2012 8:56 AM To: Sergio Villar Senin Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? From: Sergio Villar Senin svil...@igalia.com To: webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 4:46 PM Subject: Re: [webkit-dev] Moving to Git? En 08/03/12 13:35, Ashod Nakashian escribiu: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not. Ahh, the days when one didn't have to download anything to start hacking away... But seriously, why should I care about OS X when Windows comes packed with git?/sarcasm Anyway I'd be really pleased if that move happens. Same here. And my hope is that there are many more of us. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?
On 08.03.12 01:57, Levi Weintraub wrote: On Wed, Mar 7, 2012 at 4:50 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Wed, Mar 7, 2012 at 4:44 PM, Darin Fisher da...@chromium.org mailto:da...@chromium.org wrote: Hrm, if the test expectations are customized already for different ports of WebKit, then why not support replacing a PNG file with a HTML file that is intended to generate exactly the same result? How does this impair our ability to update the tests? (I realize that our current reftest system may not work like this. I'm not familiar with the details of how it works in fact, but it seems like it could be as simple as having an expected result that is a HTML file instead of a PNG file.) How do we know that we are testing what the test is intending to test after the conversion? e.g. it's possible to create a reference file that fails to catch certain bugs. This sums up my worry as well. I can imagine a bug causing a CSS test and its reference to fail in the same way, masking the failure. What if the reference is one line of text + image that represents the expected result? That way ports can share the associated png. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). Then for everything else I use git and its power locally. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard alexis.men...@openbossa.orgwrote: I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. Then for everything else I use git and its power locally. Right. Git clients are pretty nice. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, 2012-03-08 at 14:10 -0300, Alexis Menard wrote: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). We just need to keep the history linear. With good practices it's possible :) Philippe signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 12:35 PM, Alexis Menard alexis.men...@openbossa.orgwrote: On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? http://progit.org/book/ch7-4.html Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Yes, I think it's possible with a hook in the server. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Indeed it is. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Carlos Garcia Campos [carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:38 PM To: Alexis Menard Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Yes, I think it's possible with a hook in the server. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On 08.03.12 18:22, Geoffrey Garen wrote: Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally? The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea. That's a good point. I'm curious though, what are the main sicking points? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
From: Ryosuke Niwa rn...@webkit.org To: Alexis Menard alexis.men...@openbossa.org Cc: Ashod Nakashian ashodnakash...@yahoo.com; WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 9:19 PM Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard alexis.men...@openbossa.org wrote: I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. Then for everything else I use git and its power locally. Right. Git clients are pretty nice. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
From: Geoffrey Garen gga...@apple.com To: Ashod Nakashian ashodnakash...@yahoo.com Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 9:22 PM Subject: Re: [webkit-dev] Moving to Git? Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally? Switch by fiat? Not by a long shot. The call is to reevaluate the suggestion. Indeed, we must improve the infrastructure as long as there are users, regardless of any plans of moving VCs. The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea. This is part of the goal - to see how many still use SVN, what's holding them back from the move and how we can help them and the community to make the transition to what is deemed by most (my estimate) to be superior. On that count, what feature do you find in svn that is missing from git, or put differently, why is git not as good as svn for you? Geoff On Mar 8, 2012, at 4:35 AM, Ashod Nakashian wrote: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. [1] https://bugs.webkit.org/show_bug.cgi?id=79509#c6 [2] http://trac.webkit.org/wiki/Moving%20to%20Git [3] http://trac.webkit.org/wiki/Moving%20to%20Git?action=history Thanks for lending an ear, -Ash ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Alexis, imagine not pushing directly but going through an intermediate system like in Qt - where history is nicely linear now :) Simon From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of ext Alexis Menard [alexis.men...@openbossa.org] Sent: Thursday, March 08, 2012 18:35 To: Konrad Piascik Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I didn't have my subversion config set correctly. I went to fix up my commits from yesterday and realized that a very large percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. Is anyone opposed to me doing a bulk fix for all the pngs? find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type image/png On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash -- *From:* Simon Fraser simon.fra...@apple.com *To:* Eric Seidel e...@webkit.org *Cc:* WebKit Development webkit-dev@lists.webkit.org *Sent:* Thursday, March 8, 2012 3:37 AM *Subject:* Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
(For those valuable contributors who are against Git and have manifested somehow here, please do not take it personally) IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. In my opinion, SVN concepts are completely obsolete these days. It is hard to me to even hear someone arguing in favor of SVN against GIT, but I respect anyone's opinion. I just do not feel them strong enough given the whole context. On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? From: webkit-dev-boun...@lists.webkit.org [ webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [ rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.com mailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 9:22 AM, Geoffrey Garen gga...@apple.com wrote: Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally? The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea. People have been improving our git infrastructure constantly; I think the point is the converse ... it's getting harder to support SVN, and supporting two systems does impose a cost (at least to the people like me that do hack on the infrastructure :). That said, I have to agree that it's nice to be able to see a monotonically increasing number in the change history. Even if you have a single linear branch in the git master, you don't have that. Maybe there is a practice for getting an equivalent using labels or tags in git repos that I don't know about? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. This is an example of what I mean by fiat: Step 1: Force a change upon people Step 2: … Step 3: A greater good is achieved Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
Ojan, There are also quite a few files with the svn:executable property set (359 in LayoutTests alone, by my count), I think most of which are erroneous. Philip On Thu, Mar 8, 2012 at 3:05 PM, Ojan Vafai o...@chromium.org wrote: Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I didn't have my subversion config set correctly. I went to fix up my commits from yesterday and realized that a very large percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. Is anyone opposed to me doing a bulk fix for all the pngs? find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type image/png On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash -- *From:* Simon Fraser simon.fra...@apple.com *To:* Eric Seidel e...@webkit.org *Cc:* WebKit Development webkit-dev@lists.webkit.org *Sent:* Thursday, March 8, 2012 3:37 AM *Subject:* Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Hi Geoff. I might have missed your point. Who is trying to force you to change something? I would love to understand the other side for sure... On Thu, Mar 8, 2012 at 3:20 PM, Geoffrey Garen gga...@apple.com wrote: IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. This is an example of what I mean by fiat: Step 1: Force a change upon people Step 2: … Step 3: A greater good is achieved Geoff -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you -jochen - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote: On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. git pull does the same (if no conflicts were found, but the same pain will happen on svn in case of conflicts) or git fetch origin; git rebase origin/master I remember the days were I switched from svn to git, blaming git for force me to type additional commands, today I'm just regrets for the blames and can't think in another VCS than git :-). - Ryosuke -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-patch and git revisions (resolved)
Hi all, I have just landed a change to webkit-patch that tweaks the -g handling slightly as a result of the discussion in the thread from last week. The patch in question is in https://bugs.webkit.org/show_bug.cgi?id=76958 . In short, I have added a new UPSTREAM ref that will resolve to the tracking branch name, and I changed ref to resolve to diff the working copy against ref. In particular, if you used HEAD.. before, you'll need HEAD now - this make HEAD.. no longer do the opposite of what git does with that syntax ;). Otherwise, webkit-patch should be unchanged (including other uses of -g). In longer, more examples: Assume you have a branch 'foo' with one commit 'commit1', and then a branch 'bar' branched off of foo (using checkout -t -b foo) with another 'commit2', and then a local working copy with 'commit3': webkit-patch -g foo = git diff foo^..foo = (commit1), as before webkit-patch -g foo.. = git diff foo..HEAD = (commit1, commit2) webkit-patch -g foo = git diff foo = (commit1, commit2, commit3) webkit-patch -g UPSTREAM = git diff foo^..foo = (commit1) (since foo is the upstream branch of bar, the current branch) webkit-patch -g UPSTREAM.. = git diff foo^..HEAD webkit-patch -g UPSTREAM = git diff foo = (commit1, commit2, commit3) Note that -g foo is different from what 'git diff foo' would do; it matches 'git cherry-pick foo' instead and is left this way to match existing usage of webkit-patch. Comments/questions/bugs welcome :). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Well, not quite. The equivalent to svn up is git pull --rebase origin/master (which should be the default, as git merge is the bit that horribly confuses people - but I digress). I'm not sure if it will fill in the origin/master part automatically. What Ryosuke seems to be complaining about is that if you have changes to your working copy, svn up will automatically merge them, which could lead to conflicts you have to untangle, while git pull --rebase will give an error telling you you must commit or stash them first. So the real equivalent to svn up is git stash git pull --rebase origin/master git stash pop. And git stash pop will start pretty much the same merging process as svn's if there are conflicts. This is only slightly more complicated, and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like git stash show or git stash branch, whereas unless svn has features I don't know about, if svn up does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve. And you can always make a git-up script that does git stash git pull --rebase origin/master git stash pop, so the command you type won't even be any longer than svn up, but will give you more safety. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Hugo Parente Lima [hugo.l...@openbossa.org] Sent: Thursday, March 08, 2012 3:45 PM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote: On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. git pull does the same (if no conflicts were found, but the same pain will happen on svn in case of conflicts) or git fetch origin; git rebase origin/master I remember the days were I switched from svn to git, blaming git for force me to type additional commands, today I'm just regrets for the blames and can't think in another VCS than git :-). - Ryosuke -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger joc...@chromium.org wrote: On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.org wrote: The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you I do that at least 5-6 times a day if not more. On Thu, Mar 8, 2012 at 12:58 PM, John Yani van...@gmail.com wrote: I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. What do you mean? # fetch from origin master and merge into the current branch git pull origin master Huh? That's not equivalent to svn up at all. On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote: What Ryosuke seems to be complaining about is that if you have changes to your working copy, svn up will automatically merge them, which could lead to conflicts you have to untangle, while git pull --rebase will give an error telling you you must commit or stash them first. So the real equivalent to svn up is git stash git pull --rebase origin/master git stash pop. And git stash pop will start pretty much the same merging process as svn's if there are conflicts. Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically. This is only slightly more complicated I'd say astoundingly more complicated because of and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like git stash show or git stash branch whereas unless svn has features I don't know about, if svn up does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve. But I can just run svn diff to create a backup if I really wanted to save the original change. But I've never had a trouble merging things so it's hard for me to tell if that's really useful or not. And you can always make a git-up script that does git stash git pull --rebase origin/master git stash pop, so the command you type won't even be any longer than svn up, but will give you more safety. That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
Go for it! rs=me. Better yet would be automating that process, and/or making one of the tools warn if they're missing... On Thu, Mar 8, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote: Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I didn't have my subversion config set correctly. I went to fix up my commits from yesterday and realized that a very large percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. Is anyone opposed to me doing a bulk fix for all the pngs? find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type image/png On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash From: Simon Fraser simon.fra...@apple.com To: Eric Seidel e...@webkit.org Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 3:37 AM Subject: Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing
On Mar 8, 2012, at 12:05 PM, Ojan Vafai o...@chromium.org wrote: Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I didn't have my subversion config set correctly. I went to fix up my commits from yesterday and realized that a very large percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. Is anyone opposed to me doing a bulk fix for all the pngs? No. I have done this myself multiple times in the past. find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type image/png I tend to be more conservative and only set the property on PNGs that don’t already have it set to something. On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash From: Simon Fraser simon.fra...@apple.com To: Eric Seidel e...@webkit.org Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 3:37 AM Subject: Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
I agree that git's hashes are less friendly than the monotonically increasing commit numbers from svn or p4. I've occasionally been given a pair of git hashes and had no idea which one came first, or even if they were in the same branch. git log --oneline hash is a pretty simple way to list all the commits coming before the given hash, so you can see the order of them. Other than that, maybe a post-commit hook that automatically puts a Aside: here's a neat command to map git hash's to svn-style ascending numbers: git log --oneline hash|cat -b $ git log --oneline e865bb0|cat -b|head 1 e865bb0 [Qt WK2] Remove duplicate code related to dialog handling in QQuickWebView https://bugs.webkit.org/show_bug.cgi?id=80557 2 a6b3dd6 Fix flaky test by decreasing granularity of cues (cues cover longer time intervals). The flakiness seems to appear because the video is paused synchronously, while missed events events are dispatched asynchronously. 3 9e20583 [Qt] Rebaseline after r110072. 4 4e072d9 [Qt] Windows build fix.ommit 5 7c7ab53 [chromium] Unreviewed gardening. 6 7c004bc Web Inspector: The function had to return a hash but it returned just address. https://bugs.webkit.org/show_bug.cgi?id=80591 7 d4c2667 Unreviewed single line fix. The function had to return a hash but it returned just address. 8 7b5de0b [chromium] Unreviewed gardening. 9 5540031 shadow should be rendered correctly. https://bugs.webkit.org/show_bug.cgi?id=78596 10 9040697 Speech JavaScript API: SpeechRecognitionAlternative, Result and ResultList https://bugs.webkit.org/show_bug.cgi?id=80424 ...except of course that this is descending numbers (1 is the most recent) and they're not persistent, so telling somebody commit 8 only works if they're starting from the same point. Which makes them not incredibly useful. From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 4:25 PM To: Joe Mason Cc: Hugo Parente Lima; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger joc...@chromium.orgmailto:joc...@chromium.org wrote: On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you I do that at least 5-6 times a day if not more. On Thu, Mar 8, 2012 at 12:58 PM, John Yani van...@gmail.commailto:van...@gmail.com wrote: I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. What do you mean? # fetch from origin master and merge into the current branch git pull origin mtaster Huh? That's not equivalent to svn up at all. On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.commailto:jma...@rim.com wrote: What Ryosuke seems to be complaining about is that if you have changes to your working copy, svn up will automatically merge them, which could lead to conflicts you have to untangle, while git pull --rebase will give an error telling you you must commit or stash them first. So the real equivalent to svn up is git stash git pull --rebase origin/master git stash pop. And git stash pop will start pretty much the same merging process as svn's if there are conflicts. Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically. This is only slightly more complicated I'd say astoundingly more complicated because of and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like git stash show or git stash branch whereas unless svn has features I don't know about, if svn up does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve. But I can just run svn diff to create a backup if I really wanted to save the original change. But I've never had a trouble merging things so it's hard for me to tell if that's really useful or not. And you can always make a git-up script that does git stash git pull --rebase origin/master git stash pop, so the command you type won't even be any longer than svn up, but will give you more safety. That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we
Re: [webkit-dev] Moving to Git?
It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) And then there is the status quo: 3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so. One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off. If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider: A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems. Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those? Regards, Maciej On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote: (For those valuable contributors who are against Git and have manifested somehow here, please do not take it personally) IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. In my opinion, SVN concepts are completely obsolete these days. It is hard to me to even hear someone arguing in favor of SVN against GIT, but I respect anyone's opinion. I just do not feel them strong enough given the whole context. On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote: It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) There appear to be scripts on the interweb that would allow access to a git repo over svn. I would be against doing this here (if we're going to allow svn access at all, we might as well stay with what we have). I believe that a git repo would allow slightly easier cloning and branching, and would make the overall system more reliable (because we wouldn't have to worry about the git/svn bridge breaking or getting corrupted). I don't think either of these reasons is particularly compelling, although I have no real insight into the uptime / ops costs of keeping the two repos in sync vs. only a git repo. I think the major benefit in moving git-only would be to simplify the tooling and the documentation for the project (we wouldn't have to document how to access everything two or three different ways). I am uncertain but skeptical that the tooling benefit outweighs the cost of the conversion. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote: It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) And then there is the status quo: 3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so. One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off. If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider: A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems. Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those? To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull as data are send compressed from the server. To git user : - Using git push rather than having to use git-svn (which you need to keep in sync). - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts The real downside is for the svn users to learn a bit git workflow. I'm forgetting stuff for sure. Regards, Maciej On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote: (For those valuable contributors who are against Git and have manifested somehow here, please do not take it personally) IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. In my opinion, SVN concepts are completely obsolete these days. It is hard to me to even hear someone arguing in favor of SVN against GIT, but I respect anyone's opinion. I just do not feel them strong enough given the whole context. On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of
Re: [webkit-dev] Moving to Git?
On Fri, Mar 9, 2012 at 8:25 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote: What Ryosuke seems to be complaining about is that if you have changes to your working copy, svn up will automatically merge them, which could lead to conflicts you have to untangle, while git pull --rebase will give an error telling you you must commit or stash them first. So the real equivalent to svn up is git stash git pull --rebase origin/master git stash pop. And git stash pop will start pretty much the same merging process as svn's if there are conflicts. Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically. And you can always make a git-up script that does git stash git pull --rebase origin/master git stash pop, so the command you type won't even be any longer than svn up, but will give you more safety. That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git. I fully support scripts specific to the WebKit workflow that wrap the VCS specifics. In my former role, I spoke to developers to identify their most common sequences of actions when synchronising their code and what information they needed when a step failed. I then wrote a common script that would execute as much of the process as it could and provide information and instruction on failure. This was a boon to productivity as in the common case, synchronisation was sub-second, and in the uncommon case they no longer had to dig up the relevant information before resolving conflicts. I think we ought to streamline the git workflow before we start trying to proselytise Subversion users. :) The monotonic labels that Ryosuke desires are known in git language as generation numbers. If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list. -- David Barr. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 7:30 PM, Alexis Menard alexis.men...@openbossa.org wrote: On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote: It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) And then there is the status quo: 3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so. One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off. If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider: A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems. Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those? To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull as data are send compressed from the server. To git user : - Using git push rather than having to use git-svn (which you need to keep in sync). - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts - Bot maintainers : Power outage or network interruption in the middle of a svn checkout/up lock the repo sometimes and you need to manually svn cleanup the checkout (maybe someone have a tool or script to avoid that???). I had much more svn locked repos than git dead checkout because of interruptions. The real downside is for the svn users to learn a bit git workflow. I'm forgetting stuff for sure. Regards, Maciej On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote: (For those valuable contributors who are against Git and have manifested somehow here, please do not take it personally) IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end. In my opinion, SVN concepts are completely obsolete these days. It is hard to me to even hear someone arguing in favor of SVN against GIT, but I respect anyone's opinion. I just do not feel them strong enough given the whole context. On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian
Re: [webkit-dev] Moving to Git?
Am 08.03.2012 um 23:30 schrieb Alexis Menard: On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote: It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) And then there is the status quo: 3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so. One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off. If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider: A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems. Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those? To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull as data are send compressed from the server. *) Easier way to setup local mirrors (for buildbots). See discussion at https://lists.webkit.org/pipermail/webkit-dev/2012-March/019699.html To git user : - Using git push rather than having to use git-svn (which you need to keep in sync). - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts The real downside is for the svn users to learn a bit git workflow. I'm forgetting stuff for sure. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote: The monotonic labels that Ryosuke desires are known in git language as generation numbers. If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list. slightly-offtopic, but I had not heard of generation numbers before. Based on a cursory web-learning pass (*), it sounds like they're not quite the same thing as SVN revisions, since SVN revision numers are unique to a repo, and two revisions on two different branches may have the same generation number. Since we do actually keep branches in the master repo, this wouldn't quite be the same (although it might possibly be acceptable). Please correct me if I'm wrong ... -- Dirk (*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
I think it would look the same, except for instead of monotonically increasing decimal numbers in the revision column, you'd see random hexadecimal ones (typically 6-8 digits long). On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschler lforsch...@apple.com wrote: Could someone enlighten me on what this page would look like after a conversion to git? http://build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100 Lucas On Mar 8, 2012, at 3:22 PM, Dirk Pranke wrote: On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote: The monotonic labels that Ryosuke desires are known in git language as generation numbers. If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list. slightly-offtopic, but I had not heard of generation numbers before. Based on a cursory web-learning pass (*), it sounds like they're not quite the same thing as SVN revisions, since SVN revision numers are unique to a repo, and two revisions on two different branches may have the same generation number. Since we do actually keep branches in the master repo, this wouldn't quite be the same (although it might possibly be acceptable). Please correct me if I'm wrong ... -- Dirk (*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exporting symbols for building .so/.dll's
(From the right address...)
Hi Ami,
I don't think there is a consensus about that. Here is my
understanding of the current status of the export symbol management:
At first, each port has different way to split libraries. For example,
- A) Mac port (WebKit1) splits WebKit into three frameworks: WebCore,
JavaScriptCore and WebKit.
(The last one is for Objective-C API which wraps WebCore.)
- B) Some others split it into JavaScriptCore and WebCore+WebKit.
- C) Chromium chooses yet another variation: making a single library
for whole WebKit.
This difference is one of the reasons why the way to export symbols is
different among ports.
For ports on approach C, it doesn't matter which WebCore/JSC API is
used from WebKit API layer because they are built in the same library.
For ports on approach B, only the symbols exported from JSC matter.
The dependency from WebKit API to WebCore doesn't.
For ports on approach A, symbols exported both from JSC and WebCore
matter because these two have their own libraries. APIs of these
libraries should be exported to be used by WebKit API library.
Also, there are port specific WebKit APIs (like WebFrame and WebString
of Chromium.) which have their own ways to export symbols. But in
general, people other than the port maintainers don't need to care
about that because there are few chances to change such APIs.
---
I'd try to clarify some more detail:
For JSC API, which A and B folks care about, there are two ways to
export it.
- For Windows port, there is JavaScriptCore.def.
- For Mac (and WX?) port, there are macro-based annotations like
JS_EXPORT, WTF_EXPORT_PRIVATE.
I'm in the way to eliminate JavaScriptCore.def by replacing it with
these annotations, but the migration isn't finished yet.
(http://wkb.ug/76257)
For WebCore API, we only need to care about WebCore.exp.in because Mac
port is the only one which follows A pattern. (I remember Windows
port used to use this pattern. But it looks no longer the case. Maybe
they changed the way when they switched to WebKit2. But my memory
might be just wrong...)
---
Having that long said, back to the original question:
Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific
.exp.in-style files, one per layer from which I need to export (WebCore,
WTF, WebKit). And build the build-time machinery to use them. I don't
really know what's involved here and would appreciate any pointers/hints
people had if this is the way to go.
3) Something else (preferably unifying other ports' approaches).
- If the API is under JavaScriptCore/ (or WTF/), I'd recommend to use
JS_EXPORT and WTF_EXPORT_PRIVATE because we are under transition to
this path.
- If the API is under WebKit/chromium/, we can just use WEBKIT_EXPORT as before.
- If the API is under WebCore/, there is no consensus except we
already have WebCore.exp.in.
My personal preference is to introduce WebCore version of export
macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
of WebCore.exp.in in the future.
Another possibility is to ride existing WebCore.exp.in somehow. Yet
another approach could be just giving up to have the unit test as a
separate binary and build it into the library for non-prod
configuration. The last one seems exactly what you are trying to avoid
though... One clear thing is that maintaining yet another exp file
will be bad news for almost everyone ;-)
Anyway, I'd like to hear thoughts from other folks.
Bests,
--
morrita
___
webkit-dev mailing list
On Fri, Mar 9, 2012 at 12:52 PM, Ami Fischman fisch...@chromium.org wrote:
Hi webkittens,
The over-all question: how should webkit libraries declare which symbols
they export?
The trigger for the question: as described in bug 80062, the chromium
shared-library-based build links test code into the (non-test) libwebkit.so
target, which is terrible.
The details:
I took a crack at fixing the above bug (see patch in the bug) by pulling the
test files out of the non-test build target, and sprinkling various
{WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
discovered by build-time and run-time failures). This style of export
declaration is what the webkit codebase does in various places
(WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
the chromium project uses for its sub-components.
But I'm told other ports use different mechanisms such as .exp.in files for
apple/mac (and maybe others for other ports? IDK).
Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific
.exp.in-style files, one per layer from which I need to export (WebCore,
WTF, WebKit). And
