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,
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
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
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
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
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
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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 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
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
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:
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
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?
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
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
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
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...
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
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
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
(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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
(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:
54 matches
Mail list logo
