Pierre-Yves David writes:
> On 10/14/2016 05:48 PM, Erik van Zijst wrote:
>> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>> >
>> wrote:
>>
>>
>> So, thanks for exploring
At Fri, 14 Oct 2016 21:31:36 +0200,
Pierre-Yves David wrote:
>
> Could we make the flag for this 'sqldirstate-ext' to make it clearer
> that it has an external target?
Oops, sorry for lack of "-ext"
> On 10/14/2016 09:10 PM, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User
Could we make the flag for this 'sqldirstate-ext' to make it clearer
that it has an external target?
On 10/14/2016 09:10 PM, FUJIWARA Katsunori wrote:
# HG changeset patch
# User FUJIWARA Katsunori
# Date 1476456912 -32400
# Fri Oct 14 23:55:12 2016 +0900
# Node ID
# HG changeset patch
# User FUJIWARA Katsunori
# Date 1476456912 -32400
# Fri Oct 14 23:55:12 2016 +0900
# Node ID 72486917916f6d47525f721cd5b27012091122ed
# Parent d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc
# Available At
On 10/14/2016 05:48 PM, Erik van Zijst wrote:
On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>
wrote:
So, thanks for exploring possibilities to make this frontier thiner.
However, I can see some issues with
On 10/14/2016 07:29 PM, Erik van Zijst wrote:
On Fri, Oct 14, 2016 at 9:54 AM, Pierre-Yves David
wrote:
If we use the same field for either topic or name branch a changeset can
either be:
* on a named branch but no topic
* on a topic but no named branch (so
> On Oct 14, 2016, at 1:29 PM, Erik van Zijst wrote:
>
>> * on a named branch but no topic
>> * on a topic but no named branch (so default branch)
>
> Why would a topic imply that it is on the default branch? I don't
> think I see that. In my mental model a topic is
On Fri, Oct 14, 2016 at 9:54 AM, Pierre-Yves David
wrote:
> If we use the same field for either topic or name branch a changeset can
> either be:
>
> * on a named branch but no topic
> * on a topic but no named branch (so default branch)
Why would a topic imply
Erik van Zijst writes:
> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David <
> pierre-yves.da...@ens-lyon.org> wrote:
>
>>
>> So, thanks for exploring possibilities to make this frontier thiner.
>> However, I can see some issues with some aspects of this proposal,
> This loop would never stop if malformed tokens were provided. I guess you
> had a working version in which _isop() could raise IndexError.
Nice catch! I'll turn the `while True` into a `for j in xrange(i + 2,
len(tokens)):` loop instead, and avoid IndexError or looping to infinity
altogether.
# HG changeset patch
# User Martijn Pieters
# Date 1476347257 -3600
# Thu Oct 13 09:27:37 2016 +0100
# Node ID d20dd7db86044bdca79825499b913840d726d841
# Parent 9031460519503abe5dc430c8ece29d198121cd65
py3: use namedtuple._replace to produce new tokens
diff --git
# HG changeset patch
# User Martijn Pieters
# Date 1476464102 -3600
# Fri Oct 14 17:55:02 2016 +0100
# Node ID 9031460519503abe5dc430c8ece29d198121cd65
# Parent 733fb9f7bc92c694ba6bededaeb93206528c0bcd
py3: refactor token parsing to handle call args properly
The token
On 10/14/2016 05:48 PM, Erik van Zijst wrote:
On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>
wrote:
So, thanks for exploring possibilities to make this frontier thiner.
However, I can see some issues with some
On 10/14/2016 05:35 PM, Yuya Nishihara wrote:
# HG changeset patch
# User Yuya Nishihara
# Date 1476455580 -32400
# Fri Oct 14 23:33:00 2016 +0900
# Node ID 18ba0036dd81db9e45fd1a450c7f207f1b89f22c
# Parent 5cb830801855dbb63e98b948e355bc995d295bf3
revset: for x^2, do not
On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:
>
> So, thanks for exploring possibilities to make this frontier thiner.
> However, I can see some issues with some aspects of this proposal, using
> the same field for either branch or topic make them
On Thu, 13 Oct 2016 17:57:57 +0200, Pierre-Yves David wrote:
> On 10/13/2016 04:13 PM, Yuya Nishihara wrote:
> > On Thu, 13 Oct 2016 16:03:03 +0200, Mads Kiilerich wrote:
> >> On 10/13/2016 03:58 PM, Yuya Nishihara wrote:
> >>> On Thu, 13 Oct 2016 15:46:25 +0200, Mads Kiilerich wrote:
> On
On Thu, 13 Oct 2016 10:22:08 +0100, Martijn Pieters wrote:
> # HG changeset patch
> # User Martijn Pieters
> # Date 1476350485 -3600
> # Thu Oct 13 10:21:25 2016 +0100
> # Node ID 36607cf1bbd9fd4d99b607f927bc807fcc48d0ea
> # Parent 733fb9f7bc92c694ba6bededaeb93206528c0bcd
On Thu, 13 Oct 2016 13:53:13 +0200, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David
> # Date 1476359267 -7200
> # Thu Oct 13 13:47:47 2016 +0200
> # Node ID db0b3bc2e7ae19973240275fb9e3f964ecdeb019
> # Parent
On Thu, 13 Oct 2016 21:42:42 +0200, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc
> # Date 1476387731 -7200
> # Thu Oct 13 21:42:11 2016 +0200
> # Node ID 4bbdf012fafbdffd4d4402a712fdc01d3252d00c
> # Parent
FYI This is the violation of C API, explicit assignment would be
probably better (at least it's CLEAR that you're doing something
dodgy)
On Thu, Oct 13, 2016 at 9:43 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc
> # Date
On 10/12/2016 12:25 PM, Mads Kiilerich wrote:
# HG changeset patch
# User Mads Kiilerich
# Date 1476267738 -7200
# Wed Oct 12 12:22:18 2016 +0200
# Node ID 9588752fc3a6d2b5b1f40ddfc48965997270892d
# Parent 29bd20c4999865fc19ca3f0344c2c1231a318b1c
merge: clarify
On 10/13/2016 09:43 PM, Gregory Szorc wrote:
# HG changeset patch
# User Gregory Szorc
# Date 1475939263 -7200
# Sat Oct 08 17:07:43 2016 +0200
# Node ID c05716f3eb0a4a70ef1f59b51cd1b29ee683a145
# Parent c0410814002f467c24ef07ce73850ba15b306f8e
dirs: document
On 10/14/2016 09:55 AM, Philippe Pepiot wrote:
# HG changeset patch
# User Philippe Pepiot
# Date 1476267774 -7200
# Wed Oct 12 12:22:54 2016 +0200
# Node ID 617220c6b76e9faf873dbacf69baff0196b52d92
# Parent 9eb1db967e9db678e06723b26966b06f060ef36e
#
On 10/14/2016 03:03 AM, Mads Kiilerich wrote:
# HG changeset patch
# User Mads Kiilerich
# Date 1476407019 -7200
# Fri Oct 14 03:03:39 2016 +0200
# Node ID c0fd76f612735f0354102603ee630437208d8336
# Parent c0410814002f467c24ef07ce73850ba15b306f8e
demandimport:
# HG changeset patch
# User Philippe Pepiot
# Date 1476267774 -7200
# Wed Oct 12 12:22:54 2016 +0200
# Node ID 617220c6b76e9faf873dbacf69baff0196b52d92
# Parent 9eb1db967e9db678e06723b26966b06f060ef36e
# EXP-Topic record-return-code
record: return code from
Cool. I was going to author this patch when I got back home!
This patch will result in CPU regression for old clients having to re-deltify.
It would be nice to have numbers for that. I'm optimistic it is roughly the
same as the server gains and it won't be significant enough to not take the
Pierre-Yves David a écrit :
On 10/11/2016 11:39 AM, Denis Laxalde wrote:
# HG changeset patch
# User Denis Laxalde
# Date 1476176128 -7200
# Tue Oct 11 10:55:28 2016 +0200
# Node ID 1cf20c1c54cb8172816604de5e1d98d3cd62d711
# Parent
# HG changeset patch
# User Maciej Fijalkowski
# Date 1476428549 -7200
# Fri Oct 14 09:02:29 2016 +0200
# Node ID 4e80a66124279e235dec7ae8f58c0a14b0b137bf
# Parent c770219dc4c253d7cd82519ce3c74438bb2829d3
osutil: implement listdir for linux
diff --git
28 matches
Mail list logo