[Python-3000-checkins] r65620 - python/branches/py3k

[brett.cannon]

Author: brett.cannon
Date: Sun Aug 10 01:40:18 2008
New Revision: 65620

Log:
Blocked revisions 65619 via svnmerge

........
r65619 | brett.cannon | 2008-08-09 16:39:11 -0700 (Sat, 09 Aug 2008) | 3 lines

Silence warnings in csv about using reduce() when run under -3 by using
functools.reduce() instead.
........


Modified:
python/branches/py3k/ (props changed)

[Benjamin Peterson]

Brett,
You know that you can block multiply revisions at the same time,
right? It seems you are now blocking each revision separately.

On Sat, Aug 9, 2008 at 5:40 PM, brett.cannon

Post by brett.cannon
Author: brett.cannon
Date: Sun Aug 10 01:40:18 2008
New Revision: 65620
Blocked revisions 65619 via svnmerge
........
r65619 | brett.cannon | 2008-08-09 16:39:11 -0700 (Sat, 09 Aug 2008) | 3 lines
Silence warnings in csv about using reduce() when run under -3 by using
functools.reduce() instead.
........
python/branches/py3k/ (props changed)
_______________________________________________
Python-3000-checkins mailing list
Python-3000-checkins at python.org
http://mail.python.org/mailman/listinfo/python-3000-checkins

[Nick Coghlan]

Post by Benjamin Peterson
Brett,
You know that you can block multiply revisions at the same time,
right? It seems you are now blocking each revision separately.

Sometimes its useful to do one task completely (fix in 2.6, commit,
block in 3.0, commit) to make sure you don't miss anything, rather than
save all the block commands up to the end.

This also keeps the source tree is as consistent a state as possible, so
it doesn't matter if Brett gets interrupted while working on his next
fix and someone does an svnmerge before he gets back to it.

Cheers,
Nick.

[Brett Cannon]

Post by Benjamin Peterson
Brett,
You know that you can block multiply revisions at the same time,
right? It seems you are now blocking each revision separately.

Yes, I do, but I don't mind. It's two commands with a copy-and-paste
that occurs while I am doing other stuff.

Sometimes its useful to do one task completely (fix in 2.6, commit, block in
3.0, commit) to make sure you don't miss anything, rather than save all the
block commands up to the end.
This also keeps the source tree is as consistent a state as possible, so it
doesn't matter if Brett gets interrupted while working on his next fix and
someone does an svnmerge before he gets back to it.

Exactly what Nick said. I treat each fix as an atomic commit that
happens to span to branches in svn. That way I never forget anything.
Plus I have actually been committing when someone else was doing a
large merge into Py3K, so this helps prevent all of my commits from
suddenly causing someone else grief.

-Brett

[Georg Brandl]

Post by Brett Cannon

Sometimes its useful to do one task completely (fix in 2.6, commit, block in
3.0, commit) to make sure you don't miss anything, rather than save all the
block commands up to the end.
This also keeps the source tree is as consistent a state as possible, so it
doesn't matter if Brett gets interrupted while working on his next fix and
someone does an svnmerge before he gets back to it.

Exactly what Nick said. I treat each fix as an atomic commit that
happens to span to branches in svn. That way I never forget anything.

It's not like we're short of revision numbers. :)

Post by Brett Cannon
Plus I have actually been committing when someone else was doing a
large merge into Py3K, so this helps prevent all of my commits from
suddenly causing someone else grief.

This is always a problem whenever you merge/commit something to Py3k
while a large merge is done. It could only be helped if the one doing
the merge could somehow lock the branch from other updates.

Georg