Are big merges from the trunk still being made to the py3k branch? I checked in a change to csv.DictReader on the trunk yesterday evening. I will port it to py3k if necessary, but I was under the impression that the merge gnomes are constantly busy at work behind the scene. If this activity has been curtailed because we are nearly late betas or something, let me know and I'll do it myself. Thx, Skip
On Sat, Aug 9, 2008 at 7:40 AM, <skip@pobox.com> wrote:
Are big merges from the trunk still being made to the py3k branch? I checked in a change to csv.DictReader on the trunk yesterday evening. I will port it to py3k if necessary, but I was under the impression that the merge gnomes are constantly busy at work behind the scene. If this activity has been curtailed because we are nearly late betas or something, let me know and I'll do it myself.
They's still happening, as irregularly scheduled as ever. However if you think your change requires any kind of manual help to be merged, it's better to do the merge yourself for just that revision: svnmerge.py merge -rNNNNN. That way it'll be recorded as merged and a later big merge will skip it. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> However if you think your change requires any kind of manual help Guido> to be merged, it's better to do the merge yourself for just that Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded Guido> as merged and a later big merge will skip it. Looks like there's a bit of manual work to do (replacing "try/finally" with "with", for example). I don't know what svnmerge.py is though and don't see it in my svn tools or my trunk sandbox: ~% cd ~/src/python/trunk/ trunk% find . -name svnmerge.py trunk% like svn /usr/bin/svn /usr/bin/svnadmin /usr/bin/svndumpfilter /usr/bin/svnlook /usr/bin/svnserve /usr/bin/svnsync /usr/bin/svnversion Skip
Google for it. It's worth learning. :-) On Sat, Aug 9, 2008 at 9:37 AM, <skip@pobox.com> wrote:
Guido> However if you think your change requires any kind of manual help Guido> to be merged, it's better to do the merge yourself for just that Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded Guido> as merged and a later big merge will skip it.
Looks like there's a bit of manual work to do (replacing "try/finally" with "with", for example). I don't know what svnmerge.py is though and don't see it in my svn tools or my trunk sandbox:
~% cd ~/src/python/trunk/ trunk% find . -name svnmerge.py trunk% like svn /usr/bin/svn /usr/bin/svnadmin /usr/bin/svndumpfilter /usr/bin/svnlook /usr/bin/svnserve /usr/bin/svnsync /usr/bin/svnversion
Skip
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
>> Looks like there's a bit of manual work to do (replacing >> "try/finally" with "with", for example). Martin> Why that? Shouldn't the 2.6 code already use the with statement? The csv test code uses try/finally on trunk but with on py3k. Skip
Martin> Why that? Shouldn't the 2.6 code already use the with statement? >> The csv test code uses try/finally on trunk but with on py3k. Martin> So why doesn't it use with on the trunk? I don't know. I sure wasn't going to change that code at this point. Skip
On Sat, Aug 9, 2008 at 9:37 AM, <skip@pobox.com> wrote:
Guido> However if you think your change requires any kind of manual help Guido> to be merged, it's better to do the merge yourself for just that Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded Guido> as merged and a later big merge will skip it.
Looks like there's a bit of manual work to do (replacing "try/finally" with "with", for example). I don't know what svnmerge.py is though and don't see it in my svn tools or my trunk sandbox:
As always, the dev FAQ has the answer you are looking for: http://python.org/dev/faq/#how-do-i-merge-between-branches .
I don't know what svnmerge.py is ...
As always, the dev FAQ has the answer you are looking for: http://python.org/dev/faq/#how-do-i-merge-between-branches .
OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the changes with the commit message svnmerge generated. Am I supposed to block either the earlier revision (65605) from being merged from trunk to py3k or the later revision (65611) from being merged from py3k to trunk? Thx, Skip
If you use svnmerge properly you won't have to block anything in this case. Blocking is used to mark revs that are applied to 2.6 but should *not* apply to 3.0. We never merge from py3k to the trunk, only from the trunk to py3k. --Guido On Sat, Aug 9, 2008 at 12:50 PM, Skip Montanaro <skip@pobox.com> wrote:
I don't know what svnmerge.py is ...
As always, the dev FAQ has the answer you are looking for: http://python.org/dev/faq/#how-do-i-merge-between-branches .
OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the changes with the commit message svnmerge generated. Am I supposed to block either the earlier revision (65605) from being merged from trunk to py3k or the later revision (65611) from being merged from py3k to trunk?
Thx,
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> If you use svnmerge properly you won't have to block anything in Guido> this case. Let's assume I used it correctly. (That, of course, remains to be seen.) What about the checkin I did will tell someone running svnmerge later that r65605 has already been merged to py3k? Skip
skip@pobox.com schrieb:
Guido> If you use svnmerge properly you won't have to block anything in Guido> this case.
Let's assume I used it correctly. (That, of course, remains to be seen.) What about the checkin I did will tell someone running svnmerge later that r65605 has already been merged to py3k?
svnmerge stores information about merged and blocked revisions in SVN properties of the root directory. In your case, you didn't commit the property change, so svnmerge doesn't assume 65605 as integrated yet. If you still have the property change in your working copy, please commit it. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg> svnmerge stores information about merged and blocked revisions in Georg> SVN properties of the root directory. In your case, you didn't Georg> commit the property change, so svnmerge doesn't assume 65605 as Georg> integrated yet. If you still have the property change in your Georg> working copy, please commit it. Ah, ok. Done. I guess I shouldn't have specified the files to commit. I should have committed everything. Skip
skip@pobox.com schrieb:
Georg> svnmerge stores information about merged and blocked revisions in Georg> SVN properties of the root directory. In your case, you didn't Georg> commit the property change, so svnmerge doesn't assume 65605 as Georg> integrated yet. If you still have the property change in your Georg> working copy, please commit it.
Ah, ok. Done. I guess I shouldn't have specified the files to commit. I should have committed everything.
Yep; thankfully svnmerge makes sure the working copy is clean before merging. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (6)
-
"Martin v. Löwis" -
Brett Cannon -
Georg Brandl -
Guido van Rossum -
Skip Montanaro -
skip＠pobox.com