Mark Hammond writes:
> On 5/08/2009 3:56 PM, Ben Finney wrote:
> > Mark Hammond writes:
> >
> >> Let's say I make a branch of the hg repo, myself and a few others work
> >> on it committing as we go, then attempt to merge back upstream. Let's
> >> say some of the early commits on that clone intr
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced "bad" line
endings. I'm guessing I wo
On Tue, Aug 4, 2009 at 5:43 PM, Mark Hammond wrote:
> I'm more than willing to help on this; I haven't resurrected my stale patch
> because I find win32text only 1/2 a solution that doesn't work in practice.
> Therefore that patch is as stale for me as it is anyone. However, if a plan
> is put in
Mark Hammond writes:
> Let's say I make a branch of the hg repo, myself and a few others work
> on it committing as we go, then attempt to merge back upstream. Let's
> say some of the early commits on that clone introduced "bad" line
> endings. I'm guessing I would be forced to make a number of
>
Mark Hammond:
> Thanks Nick; I didn't want to be the only one saying that. There is a fine
> line between asserting reasonable requirements for Windows users and being
> obstructionist and unhelpful, and I'm trying to stay on the former side :)
I haven't commented on this issue before because
On 4/08/2009 7:20 PM, Nick Coghlan wrote:
Dirkjan Ochtman wrote:
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
You seem to advocate a two-step approach: enforce line endings through
win32text, catch any erro
On Mon, Aug 3, 2009 at 23:06, "Martin v. Löwis" wrote:
> > empty: keep-clone?
>
> I use that as a branch to tell build slaves to clean out their
> current checkouts. So keep-clone sounds right, assuming it is possible
> to target buildslaves at either clones or branches (which, IIUC, would
> be n
Eric Pruitt wrote:
> On Tue, Aug 4, 2009 at 04:27, Nick Coghlan wrote:
>> Eric Pruitt wrote:
>>> In my GSoC project, I have implemented asnychronous I/O in
>>> subprocess.Popen. Since the read/write operations are asynchronous, the
>>> program may have already exited by the time one calls the async
On Tue, Aug 4, 2009 at 04:27, Nick Coghlan wrote:
> Eric Pruitt wrote:
>> In my GSoC project, I have implemented asnychronous I/O in
>> subprocess.Popen. Since the read/write operations are asynchronous, the
>> program may have already exited by the time one calls the asyncread
>> function I have i
Dirkjan Ochtman wrote:
>
> okkoto-sizeof
strip - It's an 2008 Google Summer of Code project. The important changes have
been applied in r63856.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Mon, Aug 03, 2009 at 12:51:36PM +0200, Dirkjan Ochtman wrote:
> amk-mailbox: keep-clone?
strip -- this branch was for working on a fix for
http://bugs.python.org/issue1599254, but the actual work in the branch
is available as the patches attached to that item.
--amk
___
Dirkjan Ochtman wrote:
> On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis" wrote:
>> I don't know what your plan is wrt. release tags, i.e. whether you
>> want to keep them all. If you are stripping out some of the branches,
>> but plan to keep the release tags, I wonder what the tags look like.
>
>
Eric Pruitt wrote:
> In my GSoC project, I have implemented asnychronous I/O in
> subprocess.Popen. Since the read/write operations are asynchronous, the
> program may have already exited by the time one calls the asyncread
> function I have implemented. While it returns the data just fine, I have
Dirkjan Ochtman wrote:
>>> * commit hooks be implemented to enforce this - but this should not be
>>> necessary if the above was implemented and socially enforced.
>
> You seem to advocate a two-step approach: enforce line endings through
> win32text, catch any errors that slipped through in a hoo
Comments on some of the branches I've had involvement with...
On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtman wrote:
> py3k-short-float-repr: strip streamed-merge
Sounds fine.
> py3k-issue1717: keep-clone
I don't think there's any need to keep this branch; its contents were
all merged (in pi
15 matches
Mail list logo
