[admin] Some tips on using Mercurial and dvcs.w3.org
[ Bcc: public-{webapps,webevents,pointer-events,webapps-testsuite} ]
If you use hg @ W3C, please see the info below from Alexandre.
On 1/29/13 2:18 PM, ext Alexandre Bertails wrote:
Hi,
I wanted to share some tips about the use of Mercurial and
dvcs.w3.org. It's based on very common issues that people are running
into.
do not use "tip" in the ED URL
--
For Mercurial, "tip" is a virtual revision for the latest changeset
among all branches.
So, instead of using
https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp.html
you may want to use
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
Instead of "default", you can use whatever branch is
available. "default" will be there by default.
do not force an `hg push`
-
When your Mercurial client tells you that you're about to create a
remote head, DO NOT USE "-f" TO FORCE THE OPERATION. That's bad. Very
bad.
commit before pull/merge
Always `hg commit` before synchronizing repositories or you'll loose
data.
inspect the history tree
Run the following command to understand what happened:
[[
hg glog --template '{node|short}: {desc}\n' | head -55
]]
That's also a quick and easy way to know who to blame :-)
cut heads
-
To know about all the heads:
[[
hg heads
]]
And that's how the French cut heads:
[[
hg merge -r THE_REVISION_OF_THE_OTHER_HEAD
]]
(don't forget to commit!)
I hope this helps.
Alexandre, W3C Systems Team.
Re: [File API] About Partial Blob Data, XHR and Streams API
On Jan 22, 2013, at 9:42 AM, Cyril Concolato wrote: > Hi Arun, > > Le 22/01/2013 15:04, Arun Ranganathan a écrit : >> Hi Cyril, >> >> >> 1) I'm wondering why in progressive mode, does the spec say: " partial Blob >> data is an ArrayBuffer [TypedArrays] object consisting of the bytes loaded >> so far". Why isn't it the bytes loaded since the previous progress event? >> >> AR: It is always a new ArrayBuffer. The phraseology "so far" could be >> replaced by "bytes loaded since the previous progress event" though I'm not >> always sure that will be the case. > I understood from Jonas' answer that it was a new ArrayBuffer. What remained > unclear was the content of the ArrayBuffer: all the data from the beginning > of the read operation (which was problematic), or only the data read since > the previous progress event (which I prefer). If, as you say, this is latter > option, then please fix the spec. as "so far" is very ambiguous. Hi Cyril: the model you propose, of deltas since the last read, is actually *not* what the spec's intent is. Your model does have advantages, but released software follows the former model, namely *all* the data since the beginning of the read operation. The partial results consist of all the bytes, starting from the beginning, but perhaps not the last byte, depending on progress event and file size. I'll have to clarify the prose, since from your question, it is clear that this isn't well described. -- A*
