Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull step...@xemacs.org wrote: No, software engineering scales up to a point, then it breaks and you need a serialization scheme. The problem is not the DVCS, it's the demand for a *centralized*, authoritative, safe, stable version. DVCS can scale at least to Linux kernel pace if you only ask for centralized authoritative.wink DVCS is No Silver Bullet, it only helps with some accidental costs of development. It doesn't help with the costs of review and testing. Yeah, Linux employs the other solution here (which Mercurial also uses, in fact, for development of Mercurial itself): only one person pushes to the central repository, that person pulls from other staging repositories as he is aware of changes being made. There are in fact problems with the current generation of DVCSes. Lack of plists on commits, for example. You'd like to have a tested property, in fact two of them (one for the committer, one for the buildbots). You'd like to have a checkpoint property, which commits would by default be ignored by log and bisect. You'd like to have an issues property, a list of issues applicable to this commit. But again, these would only reduce accidental costs. Mercurial does in fact have a mechanism to attach arbitrary metadata to changesets (the extra dictionary), but there's no easy access from the command-line. One could also argue that this is basically just a special case of smart commit message formatting, which python-dev already does, and could extend. (For example, Mozilla sometimes closes their tree to general commits, but then has a CLOSED tag that can be put in a commit message to override that.) Cheers, Dirkjan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Stephen This won't be pleasant if people are sprinting and lots of Stephen commits are coming, because you're likely to repeatedly lose Stephen the push race. But in those conditions, nothing is guaranteed Stephen to work in decentralized fashion (that's one reason why the Stephen Linux kernel uses Linus and lieutenants as a serialization Stephen mechanism). So DVCS scales up to a point, then it breaks and you need to revert to some sort of serialization scheme? 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org wrote: No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. hg does not force the developer to test, it only forces the merge. As far as I can see, the only difference between hg and svn in this regard is that svn merging was easier, because, as you say, it was done behind the scenes when one did a conflict-free commit. If there were conflicts, though, you had the same need to merge to tip as with hg, and the same lack of enforcing of the running of tests. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
R. David Murray writes: On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org wrote: No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. hg does not force the developer to test, it only forces the merge. I didn't say any VCS forces the test; I said that the workflow can (in the best case). That's also inaccurate, of course. I should have said require, not force. My understanding is that svn does not detect fast forwards, only lack of conflicts, and therefore in case of concurrent development it is possible that the repository contains a version that never existed in any developer's workspace. If that is not true, I apologize for the misinformation. If it is true, by definition developers cannot test or review what hasn't existed in their workspace; that testing and review is therefore imposed on the project as a whole, and perhaps not done until more concurrent commits have been made. On the other hand, in a DVCS this can't happen under normal circumstances. As far as I can see, the only difference between hg and svn in this regard is that svn merging was easier, because, as you say, it was done behind the scenes when one did a conflict-free commit. That's true from the point of view of the individual developer; the DVCS requires more effort of her. That is not true from the point of view of the whole project however. It would be possible for the svn-based workflow to require that after testing in one's workspace, one does an svn update, and if any changes are made to files in the workspace, the whole build and test procedure must be repeated. I don't see that that has advantages over the hg workflow, though -- it should cause an addition build-test cycle in exactly the same revision sequences that the hg workflow does. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
My understanding is that svn does not detect fast forwards, only lack of conflicts, and therefore in case of concurrent development it is possible that the repository contains a version that never existed in any developer's workspace. I can't understand how you draw this conclusion (therefore). If you do an svn up, it merges local changes with remote changes; if that works without conflicts, it tells you what files it merged, but lets you commit. Still, in this case, the merge result did exist in the sandbox of the developer performing the merge. Subversion never ever creates versions in the repository that didn't before exist in some working copy. The notion that it may have done a server-side merge or some such is absurd. If it is true, by definition developers cannot test or review what hasn't existed in their workspace; that testing and review is therefore imposed on the project as a whole, and perhaps not done until more concurrent commits have been made. You make it sound as if you have never used subversion. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/21/2011 10:44 AM, Martin v. Löwis wrote: My understanding is that svn does not detect fast forwards, only lack of conflicts, and therefore in case of concurrent development it is possible that the repository contains a version that never existed in any developer's workspace. I can't understand how you draw this conclusion (therefore). If you do an svn up, it merges local changes with remote changes; if that works without conflicts, it tells you what files it merged, but lets you commit. Still, in this case, the merge result did exist in the sandbox of the developer performing the merge. Subversion never ever creates versions in the repository that didn't before exist in some working copy. The notion that it may have done a server-side merge or some such is absurd. It does so at the *tree* level, not at an individual file level. 1) svn doesn't require you to run 'svn up' unless there is a direct change to the file you are committing. So there is plenty of opportunity to have cross-file failures. The standard example is I change foo.py's foo() function to add a new mandatory parameter. I 'svn up' and run the test suite, updating all callers to supply that parameter. You update bar.py to call foo.foo() not realizing I'm updating it. You 'svn up' and run the test suite. Both my test suite and your test suite were perfect. So we both 'svn commit'. There is now a race condition. Both of our commits will succeed. (revisions 10 and 11 lets say). Revision 11 is now broken (will fail to pass the test suite.) 2) svn's default lack of tree-wide synchronization means that no matter how diligent we are, there is a race condition. (As I'm pretty sure both 'svn commit' can run concurrently since they don't officially modify the same file.) 3) IIRC, there is a way to tell svn commit, this is my base revno, if the server is newer, abort the commit. It is used by bzr-svn to ensure we always commit tree-wide state safely. However, I don't think svn itself makes much use of it, or makes it easy to use. Blindly merging in trunk / rebasing your changes has the same hole. Though you at least can be aware that it is there, rather than the system hiding the fact that you were out of date. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HMxoACgkQJdeBCYSNAAMaewCfW3DK8hW4hBKOA+5zbyaxyptH MMQAoKGw2uWUWafBK2+Jl5A6XMK+0z9f =5R0+ -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Stephen It would be possible for the svn-based workflow to require that Stephen after testing in one's workspace, one does an svn update, and Stephen if any changes are made to files in the workspace, the whole Stephen build and test procedure must be repeated. I don't see that Stephen that has advantages over the hg workflow, though -- it should Stephen cause an addition build-test cycle in exactly the same revision Stephen sequences that the hg workflow does. It, however requires every developer to become facile, if not expert, with the ins and outs of the Python/Mercurial workflow. This discourages casual or intermittent contributions. My main contribution to the Python codebase over the past couple years has been to intercept trivial bug reports sent to the webmaster address calling out typos in the documentation or the website. Handling such reports was trivial with Subversion. Update, edit, check in. That is no longer the case with Mercurial. (And for the website will no longer be the case in the fairly near future if I understand correctly.) I believe it runs counter to the professed intention of the switch away from a centralized version control system, to make it easier for more people to contribute to Python. It certainly seems harder for this old dog. 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, Mar 21, 2011 at 7:44 PM, Martin v. Löwis mar...@v.loewis.de wrote: If you do an svn up, it merges local changes with remote changes; if that works without conflicts, it tells you what files it merged, but lets you commit. Still, in this case, the merge result did exist in the sandbox of the developer performing the merge. Subversion never ever creates versions in the repository that didn't before exist in some working copy. The notion that it may have done a server-side merge or some such is absurd. If you do an svn commit, and there are no files in conflict (or that require merging), svn will let the commit go through. It doesn't care if someone else may have updated *other* files in the meantime, so long as none of the files in the current commit were touched. Thus, if you don't do an svn up immediately before committing, you may get an implicit merge of orthogonal changesets on the server. svn will only complain if the changesets aren't orthogonal (i.e. file x.y is not up to date). This may break the buildbots if, for example, one commit changed an internal API in a backwards incompatible way, while the latter commit used that API (or vice-versa). hg broadens the check and complains if *any* files are not up to date on any of the branches being pushed, thus making it a requirement to do a hg pull and merge on all affected branches before the hg push can succeed. In theory, this provides an opportunity for the developer doing the merge to double check that it didn't break anything, in practice (at least in the near term) we're more likely to see an SVN-like practice of pushing the merged changes without rerunning the full test suite. Just accepting that, and filtering python-checkins to make it easier to skip over merge commits seems to cover the important points here, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, Mar 21, 2011 at 9:14 PM, s...@pobox.com wrote: I believe it runs counter to the professed intention of the switch away from a centralized version control system, to make it easier for more people to contribute to Python. It certainly seems harder for this old dog. I agree it's harder *now*, but I don't think it will stay that way. As best practices like installing the whitespace hook client-side evolve and are codified then the devguide can become a lot more prescriptive for new (and current) users. Remember, we knew from the beginning that core devs were going to see the least benefit from the switch, and were at the most risk of having to relearn things. The principle benefit of a DVCS (i.e. making it far, far easier to keep a clone repository up to date so that externally maintained patches are less likely to go stale) doesn't really apply to us (although we can certainly take advantage of it if we choose to - I did that myself when creating my own sandbox repository). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Martin v. Löwis writes: My understanding is that svn does not detect fast forwards, only lack of conflicts, and therefore in case of concurrent development it is possible that the repository contains a version that never existed in any developer's workspace. I can't understand how you draw this conclusion (therefore). A fast forward is a case where some ancestor of the workspace is the tip of the repository. When the tip is not an ancestor, it must contain changes not yet in the workspace. If a VCS does not check for fast-forward, then if those changes are in files not changed in the workspace, there will be no conflict, and in theory there could indeed be a silent server-side merge. QED, therefore. This seems especially plausible for VCSes that allow only a subset of files to be committed/pushed. Subversion never ever creates versions in the repository that didn't before exist in some working copy. John Arbash-Meinel disagrees with you, so I think I'll go with his opinion absent a really convincing argument otherwise. No disrespect to you intended, but John is an expert I've known for years. The notion that it may have done a server-side merge or some such is absurd. False, quite possibly; I'm not an expert on Subversion internals. Absurd, definitely not. CVS does it (and much worse, but it certainly does this too). You make it sound as if you have never used subversion. These days, it's awful hard to avoid using Subversion. However, I have no experience with committing in Python, and I don't have that much experience that I can claim to be authoritative, nor have I managed a multiuser Subversion repository. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org wrote: No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. hg does not force the developer to test, it only forces the merge. I didn't say any VCS forces the test; I said that the workflow can (in the best case). That's also inaccurate, of course. I should have said require, not force. The workflow in svn can require this same thing: before committing, you do an svn up and run the test suite. The hg workflow can not require this as well: before committing, do an hg pull -u, merge heads, and *don't* run the test suite. HG the tool does *NOT* change this aspect of things. If this change is to be made (tip should always be a repository state over which the full regrtest suite has been run), then that is a *cultural* change that we would need to make. And could have made with svn. We didn't. We probably won't with hg. Because the test suite takes to long to run and the buildbots will do it anyway. It's a discussion we could have, but as far as I can see it is completely independent of the choice of tool. Your point seems to boil down to the fact that many developers may not have thought about the fact that committing to svn without an svn up could mean they hadn't run regrtest over the *current* state of the repo. This may be true, I don't know. I did think about it. When we moved to hg, I did not re-think about it; nothing about the hg workflow change forced me to re-think about it. I did not change my habits, and that includes not re-running the test suite after a merge heads, unless there's a conflict (just like svn). That is, not only did the change in the tool and consequent change in the workflow have *zero* impact on this aspect of the way I work with CPython, it didn't even trigger me to *think* about it. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
s...@pobox.com writes: I believe it runs counter to the professed intention of the switch away from a centralized version control system, to make it easier for more people to contribute to Python. It certainly seems harder for this old dog. Well, you may be an old dog, but you're also an early adopter. That means both that you get to pay for our mistakes (our = authors of PEPs 374 and 385), and that it's going to take a while to disentangle implementation issues from the real long-run costs and benefits. Costs of transition were admitted up front. The professed intention was to make things *harder* in the short run (but as little as possible!), while making contribution to Python significantly more attractive (but not necessarily less work!) in the long run. I don't think anybody tried to hide the fact that changing habits would be required, or to claim that it would be costless. There were a few people with a Pollyanna try it, you'll like it attitude, but certainly those of us involved in PEP 374 knew better than that -- we knew there were people like you whose patterns of contribution worked just fine with the svn-based workflow and didn't need or want to change. That's why PEP 374 was necessary! Yes, based on the description you give of your principal contribution pattern, you take a complexity/effort hit in the transition. I think it can be alleviated quite a bit with the help of your reports, but that will take some time. All I can say about that time is Sorry! and Thank you for trying the system while it's still in beta. I hope you will give it some more time to shake down. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On 03/21/2011 01:34 PM, Stephen J. Turnbull wrote: Subversion never ever creates versions in the repository that didn't before exist in some working copy. John Arbash-Meinel disagrees with you, so I think I'll go with his opinion Besides, it's easy to confirm: # create a repository and two checkouts: [~/work]$ svnadmin create repo [~/work]$ svn co file:///home/hniksic/work/repo checkout1 Checked out revision 0. [~/work]$ svn co file:///home/hniksic/work/repo checkout2 Checked out revision 0. # add a file to checkout 1 [~/work]$ cd checkout1 [~/work/checkout1]$ touch a svn add a svn commit -m c1 A a Adding a Transmitting file data . Committed revision 1. # now add a file to the second checkout without ever seeing # the new file added to the first one [~/work/checkout1]$ cd ../checkout2 [~/work/checkout2]$ touch b svn add b svn commit -m c2 A b Adding b Transmitting file data . Committed revision 2. The second commit would be rejected by a DVCS on the grounds of a merge with revision 1 never having happened. What svn calls revision two is in reality based on revision 0, a fact the DVCS is aware of. The message committed revision 2, while technically accurate, is misleading if you believe the revision numbers to apply to the entire tree (as the svn manual will happily point out). It doesn't indicate that what you have in your tree when the message is displayed can be very different from the state of a freshly-checked-out revision 2. In this case, it's missing the file a: [~/work/checkout2]$ ls b This automatic merging often causes people who migrate to a DVCS to feel that they have to go through an unnecessary extra step in their workflows. But once you grasp the hole in the svn workflow, what svn does (and what one used to take for granted) tends to become unacceptable, to put it mildly. Hrvoje ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On 2011-03-21 14:40, R. David Murray wrote: On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org wrote: No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. hg does not force the developer to test, it only forces the merge. I didn't say any VCS forces the test; I said that the workflow can (in the best case). That's also inaccurate, of course. I should have said require, not force. The workflow in svn can require this same thing: before committing, you do an svn up and run the test suite. But with svn you have to redo the test after the commit *if* someone else committed just before you in the mean time, thereby changing the preconditions behind your back, thus creating a different state of the tree compared to the state in which it was at the time you ran your test. With a DVCS, you can't push in that situation. At least not without creating a new head (which would require --force in Mercurial). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mar 21, 2011, at 06:14 AM, s...@pobox.com wrote: It, however requires every developer to become facile, if not expert, with the ins and outs of the Python/Mercurial workflow. This discourages casual or intermittent contributions. My main contribution to the Python codebase over the past couple years has been to intercept trivial bug reports sent to the webmaster address calling out typos in the documentation or the website. Handling such reports was trivial with Subversion. Update, edit, check in. That is no longer the case with Mercurial. (And for the website will no longer be the case in the fairly near future if I understand correctly.) I believe it runs counter to the professed intention of the switch away from a centralized version control system, to make it easier for more people to contribute to Python. It certainly seems harder for this old dog. Does Mercurial have a way of acting like a centralized vcs to the end user, the way Bazaar does? IOW, if Skip or others were more comfortable with a centralized workflow (which is entirely valid imo), can they set up their local workspace to enable that mode of operation? If so, the devguide could describe that as a transitional step from the old svn way of doing things. -Barry signature.asc Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, 21 Mar 2011 11:25:31 -0400 Barry Warsaw ba...@python.org wrote: Does Mercurial have a way of acting like a centralized vcs to the end user, the way Bazaar does? IOW, if Skip or others were more comfortable with a centralized workflow (which is entirely valid imo), can they set up their local workspace to enable that mode of operation? I believe something like hg pull -u hg ci hg push would emulate such behaviour: it would first put your working copy in sync with remote, then let you commit, then push your new change. We cannot emulate svnmerge for porting between branches, though - and I doubt bzr can do it. That's because merges in common DVCSes are based on the DAG, while svnmerge is a prettily ad-hoc free-form thing. If so, the devguide could describe that as a transitional step from the old svn way of doing things. I think we should let things settle a few weeks before starting to describe more workflows in the devguide. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote: On Mon, 21 Mar 2011 11:25:31 -0400 Barry Warsaw ba...@python.org wrote: Does Mercurial have a way of acting like a centralized vcs to the end user, the way Bazaar does? IOW, if Skip or others were more comfortable with a centralized workflow (which is entirely valid imo), can they set up their local workspace to enable that mode of operation? I believe something like hg pull -u hg ci hg push would emulate such behaviour: it would first put your working copy in sync with remote, then let you commit, then push your new change. Actually, I meant something like 'bzr checkout': http://doc.bazaar.canonical.com/bzr.2.3/en/user-reference/checkouts-help.html This would allow individual developers to treat the repository in a centralized way like they did for svn, but still allowing other developers to work in a distributed way. We cannot emulate svnmerge for porting between branches, though - and I doubt bzr can do it. That's because merges in common DVCSes are based on the DAG, while svnmerge is a prettily ad-hoc free-form thing. Sure. If so, the devguide could describe that as a transitional step from the old svn way of doing things. I think we should let things settle a few weeks before starting to describe more workflows in the devguide. Okay. I wonder if the merge dance will get easier now that the rush of changes during Pycon settles down. -Barry signature.asc Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Thanks for the example, Hrvoje. Hrvoje This automatic merging often causes people who migrate to a DVCS Hrvoje to feel that they have to go through an unnecessary extra step Hrvoje in their workflows. But once you grasp the hole in the svn Hrvoje workflow, what svn does (and what one used to take for granted) Hrvoje tends to become unacceptable, to put it mildly. In the run-up to a release when there is lots of activity happening, do you find yourself in a race with other developers to push your changes cleanly? Suppose I am ready to check in some changes. I pull, merge, update. Run the unit tests again. That takes awhile. Then I go to push only to find someone else has already pushed a changeset. I then have to lather, rinse, repeat. This might happen more than once, especially in the last few days before an alpha (or the first beta) release. Historically, most of the churn in Python's code base occurs at that time. I don't know how likely this would be to happen, though I can imagine if it turns out to be a PITA w/ Mercurial that this is where most checkin problems (fast-forward in Stephen's terminology) would happen with Subversion. 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Barry Warsaw writes: Actually, I meant something like 'bzr checkout': No. Of the DVCSes, only bzr has that. This would allow individual developers to treat the repository in a centralized way like they did for svn, but still allowing other developers to work in a distributed way. I don't think that is true for Python, because of the forward porting workflow when a patch is relevant to several branches. They are still going to have to do a merge, and do it in the right direction. I think checkout only makes emulation of centralized workflow trivial in a single-active-branch development model. I could be wrong, but offhand I don't see how it would work. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote: Does Mercurial have a way of acting like a centralized vcs to the end user, the way Bazaar does? IOW, if Skip or others were more comfortable with a centralized workflow (which is entirely valid imo), can they set up their local workspace to enable that mode of operation? I don't think that is the main source of complexity. The more difficult and fragile part of the workflows are: * requiring commits to be cross-linked between branches * and wanting changesets to be collapsed or rebased (two operations that destroy and rewrite history). Raymond___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann adr...@cadifra.com wrote: On 2011-03-21 14:40, R. David Murray wrote: On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org wrote: No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. hg does not force the developer to test, it only forces the merge. I didn't say any VCS forces the test; I said that the workflow can (in the best case). That's also inaccurate, of course. I should have said require, not force. The workflow in svn can require this same thing: before committing, you do an svn up and run the test suite. But with svn you have to redo the test after the commit *if* someone else committed just before you in the mean time, thereby changing the preconditions behind your back, thus creating a different state of the tree compared to the state in which it was at the time you ran your test. With a DVCS, you can't push in that situation. At least not without creating a new head (which would require --force in Mercurial). So you are worried about the small window between me doing an 'svn up', seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate concern, but considering the fact that if the same thing happens in hg, the only difference is that I know about it and have to do more work[*], I don't think it really changes anything. Well, it means that if your culture uses the always test workflow you can't be *perfect* about it if you use svn[**], which I must suppose has been your (and Stephen's) point from the beginning. [*] that is, I'm *not* going to rerun the test suite even if I have to pull/up/merge, unless there are conflicts. [**] Possibly you could do it using svn locking, but even if you could it wouldn't be worth it. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2011 10:55 AM, Stephen J. Turnbull wrote: s...@pobox.com writes: I believe it runs counter to the professed intention of the switch away from a centralized version control system, to make it easier for more people to contribute to Python. It certainly seems harder for this old dog. Well, you may be an old dog, but you're also an early adopter. That means both that you get to pay for our mistakes (our = authors of PEPs 374 and 385), and that it's going to take a while to disentangle implementation issues from the real long-run costs and benefits. Costs of transition were admitted up front. The professed intention was to make things *harder* in the short run (but as little as possible!), while making contribution to Python significantly more attractive (but not necessarily less work!) in the long run. In our experience with migrating pyramid and repoze components from SVN to github, the real wins come not from merging changes inside a repository but in making it dirt-simple for people *wihtout commit privileges* to give me trivial-to-merge patches (via a public fork). I pooh-poohed that advantage at last year's PyCon when people were urging us to move to github / bitbucket; by this year's conference, I have cheerfully eaten my words. As the developer working inside the main repository, I don't find git / hg / bzr much easier to use than svn. Because I care about projects using all three, I have to know all three, while still keeping up svn chops: I find that mental overhead annoying. I don't think anybody tried to hide the fact that changing habits would be required, or to claim that it would be costless. There were a few people with a Pollyanna try it, you'll like it attitude, but certainly those of us involved in PEP 374 knew better than that -- we knew there were people like you whose patterns of contribution worked just fine with the svn-based workflow and didn't need or want to change. That's why PEP 374 was necessary! Yes, based on the description you give of your principal contribution pattern, you take a complexity/effort hit in the transition. I think it can be alleviated quite a bit with the help of your reports, but that will take some time. All I can say about that time is Sorry! and Thank you for trying the system while it's still in beta. I hope you will give it some more time to shake down. The push race problem in hg definitely bit us at PyCon this year while sprinting to get WebOb's test coverage to 100% (preparing for the Python3 port). I haven't seen that issue so much with git or bzr, but I may not have used them in such a race-friendly environment (ten or eleven developers working in parallel on the WebOb test modules). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HiM0ACgkQ+gerLs4ltQ6jvQCgy29sT5kOuq0HwzMTxNltHj5Q QH0An0kUTXiZWLTn07YvIwlWIm2LI8Gr =bZ1G -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mar 21, 2011, at 01:19 PM, R. David Murray wrote: So you are worried about the small window between me doing an 'svn up', seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate concern, but considering the fact that if the same thing happens in hg, the only difference is that I know about it and have to do more work[*], I don't think it really changes anything. Well, it means that if your culture uses the always test workflow you can't be *perfect* about it if you use svn[**], which I must suppose has been your (and Stephen's) point from the beginning. [*] that is, I'm *not* going to rerun the test suite even if I have to pull/up/merge, unless there are conflicts. I think if we really want full testing of all changesets landing on hg.python.org/cpython we're going to need a submit robot like PQM or Tarmac, although the latter is probably too tightly wedded to the Launchpad API, and I don't know if the former supports Mercurial. With the benefits such robots bring, it's also important to understand the downsides. There are more moving parts to maintain, and because landings are serialized, long test suites can sometimes cause significant backlogs. Other than during the Pycon sprints, the backlog probably wouldn't be that big. Another complication we'd have is running the test suite cross-platform, but I suspect that almost nobody does that today anyway. So the buildbot farm would still be important. -Barry signature.asc Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net wrote: We cannot emulate svnmerge for porting between branches, though - and I doubt bzr can do it. That's because merges in common DVCSes are based on the DAG, while svnmerge is a prettily ad-hoc free-form thing. The equivalent way to how we had been using svnmerge would be to use hg transplant to move patches between branches (and never merging the branches). Conversely, the current hg workflow would be similar to committing changes to the earliest applicable svn branch, then doing a full svnmerge to later branches. -- Daniel Stutzbach ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Le lundi 21 mars 2011 à 11:33 -0700, Daniel Stutzbach a écrit : On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net wrote: We cannot emulate svnmerge for porting between branches, though - and I doubt bzr can do it. That's because merges in common DVCSes are based on the DAG, while svnmerge is a prettily ad-hoc free-form thing. The equivalent way to how we had been using svnmerge would be to use hg transplant to move patches between branches (and never merging the branches). Yes, this has been discussed several times before the migration. Using hg transplant is seriously suboptimal compared to the model promoted by a DAG of changesets-based DVCS. Also, transplant has its own weaknesses. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: I don't think that is the main source of complexity. The more difficult and fragile part of the workflows are: * requiring commits to be cross-linked between branches * and wanting changesets to be collapsed or rebased (two operations that destroy and rewrite history). Yep, that sounds about right. I think in the long run the first one *will* turn out to be a better work flow, but it's definitely quite a shift from our historical way of doing things. As far as the second point goes, I'm coming to the view that we should avoid rebase/strip/rollback when intending to push to the main repository, and do long term work in *separate* cloned repositories. Then an rdiff with the relevant cpython branch will create a nice collapsed patch ready for application to the main repository (I have yet to succeed in generating a nice patch without using rdiff, but I still have some more experimentation to do with MvL's last proposed command for that before giving up on the idea). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
It does so at the *tree* level, not at an individual file level. Thanks - I stand corrected. I was thinking about the file level only (at which it doesn't do server-side merging - right?). Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Tue, 22 Mar 2011 07:32:33 +1000 Nick Coghlan ncogh...@gmail.com wrote: As far as the second point goes, I'm coming to the view that we should avoid rebase/strip/rollback when intending to push to the main repository, and do long term work in *separate* cloned repositories. Then an rdiff with the relevant cpython branch will create a nice collapsed patch ready for application to the main repository (I have yet to succeed in generating a nice patch without using rdiff, but I still have some more experimentation to do with MvL's last proposed command for that before giving up on the idea). If you use named branches it's very easy, as explained in the devguide: http://docs.python.org/devguide/committing.html#long-term-development-of-features Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
I don't think that is the main source of complexity. The more difficult and fragile part of the workflows are: * requiring commits to be cross-linked between branches * and wanting changesets to be collapsed or rebased (two operations that destroy and rewrite history). I think there would be no technical problems with giving up the latter - it's just an expression of personal taste that the devguide says what it says. As for the former, I think it objectively improves the quality of the maintenance releases to have managed backports, i.e. tracking that fixes are actually similar and correlated across branches. If you find this too complex to manage, one option would be to opt out of backporting, i.e. apply changes only to the most recent branches. In many cases, the harm done by not backporting a fix is rather small - the bug may only affect only infrequent cases, or many users may be using a different branch, anyway. Others could then still backport the change if they consider it important (and do a subsequent null merge to properly link the backport). Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/03/11 19:59, Raymond Hettinger wrote: I think if we're going to require a complex workflow, then we're going to have to expect a lot of questions. And those questions shouldn't be brushed-off with go read the tutorial, we have no time for you or words to that effect. I think we are doing some antipatterns with our current approach, battling the tools instead of joining them. Would be nice to document a complete case workflow, from patch thinking to the final push, dealing with all the little details, collapsing outgoing commits, +1 head, merging real conflicts, linealizing history, moving the patch thru branches, etc. But the fact is that some of us are still experimenting. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYX64Jlgi5GaxT1NAQLaXwQAhtZyuIZ1wYXx7yS41+bzIpZHEMbj3uCN iA/OzE1cAY55/opNHqIu1OAONKD/Y4kAm6cU/Qs2prRL2OsMwml1zPsG2Aono2iN SIqAN1YS7fagOEcDeKmPo6LbHTBpq9wuv53LBiW7xM1/ut2e5ou9DMfpf5bK6xP6 bbR4ESTGzyU= =NNNV -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
What you felt like doing after doing the rest;-? I believe your question and its answers have helped me understand hg better for when I dive in. Thanks. -- Terry Jan Reedy ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Jesus Cea writes: I think we are doing some antipatterns with our current approach, battling the tools instead of joining them. Yes. That is deliberate; see PEP 0374. I admit I personally didn't foresee the issues Nick describes with the flow of patches from one branch to another. Also, the collapse stage was completely unexpected to me (and wasn't stated as a requirement for PEP 0374), although in hindsight it seems natural for Python. The problem with joining the tools is that is a euphemism for RTFM, OK? People who are already working with hg and similar tools in their daily lives can probably make that transition in Python's workflow pretty easily, but they are not going to be very good at providing scripts for the DVCS newbies because they don't have them; they Just Do It. The DVCS newbies, OTOH, were told that the workflow would change as little as possible, and we (the PEP 0374 authors) did our best to make that possible. Unfortunately, it hasn't worked as well as hoped. I, for one, am sorry about that. I'm coming to the conclusion that those who say that Mercurial documentation should be found at the Mercurial project are wrong. I think there's a reasonably strong case (based on the explicit promise of PEP 0374 that workflows would change as little as possible) for a follow-on informational PEP providing verbal, and maybe automated, scripts for the various operations needed in the Python workflow. OTOH, people who are having problems with the workflow imposed by Mercurial need to recognize that Subversion basically ripped a big hole in the QA aspect of Python's workflow. As Nick points out, Subversion merges create new versions in the repository that *never existed in any developer's workspace* and therefore was never tested before committing. This is somewhat mitigated by buildbot testing, but that is mostly unit testing and inherently is not very good at catching problems due to interactions across modules. That is, it's not that Subversion provided a simpler way of doing the work. Rather, it hid the fact that certain work was not being done at all. hg exposes this fact. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mon, 21 Mar 2011 03:44:34 +0900, Stephen J. Turnbull step...@xemacs.org wrote: I'm coming to the conclusion that those who say that Mercurial documentation should be found at the Mercurial project are wrong. I +1. I think the dev docs should explain anything needed to do the basic Python workflow, even if that feels like repeating parts of the Mercurial docs. (If it is a large chunk, then a pointer to the exactly relevant section of the Mercurial docs would be appropriate.) On the other hand, I'm not offering to do the work, so I'll happily accept what has been produced so far (thanks, Antoine!). think there's a reasonably strong case (based on the explicit promise of PEP 0374 that workflows would change as little as possible) for a follow-on informational PEP providing verbal, and maybe automated, scripts for the various operations needed in the Python workflow. Sounds good, but someone needs to write them. You'll note that I've been asking for this for a while, but as it turns out it wasn't really possible to write them correctly until we started actually using the system. I'm still not comfortable enough to write them myself, but after I've used my chosen workflow for a while I'll do my best to write it up in more detail than my earlier post as a blog post or something. OTOH, people who are having problems with the workflow imposed by Mercurial need to recognize that Subversion basically ripped a big hole in the QA aspect of Python's workflow. As Nick points out, Subversion merges create new versions in the repository that *never existed in any developer's workspace* and therefore was never tested before committing. This is somewhat mitigated by buildbot testing, but that is mostly unit testing and inherently is not very good at catching problems due to interactions across modules. That is, it's not that Subversion provided a simpler way of doing the work. Rather, it hid the fact that certain work was not being done at all. hg exposes this fact. Given that I generally did an svn up and a final regrtest run before committing in SVN, the hole here for me was small (whatever changesets came in after my up and before my commit). Given that I do an hg pull/up and a final regrtest run before starting my merge dance and am unlikely to *re*run the regrtest after having to do an hg pull/merge heads, exactly the same size hole is going to exist in my hg workflow. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Stephen Subversion merges create new versions in the repository that Stephen *never existed in any developer's workspace* and therefore was Stephen never tested before committing. This is somewhat mitigated by Stephen buildbot testing, but that is mostly unit testing and Stephen inherently is not very good at catching problems due to Stephen interactions across modules. That is, it's not that Subversion Stephen provided a simpler way of doing the work. Rather, it hid the Stephen fact that certain work was not being done at all. hg exposes Stephen this fact. Can you provide an example of this (real or hypothetical)? It seems to me that if all you have is unit tests it matters little, if at all, whether you catch test failures before a checkin (in your local hg repo) or after (using svn + a buildbot run). The workflow of the version control system isn't going to magically expose semantic interactions across modules. It seems to me that at best the new workflow means there is a better chance of catching textual conflicts before checkin than before. 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Terry What you felt like doing after doing the rest;-? I still f*cked everything up. R. David Murray came to my rescue. Even he muffed it and had to backtrack I think, at least based on one of the comments I saw on one of the involved tracker issues. 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sun, Mar 20, 2011 at 12:40 PM, R. David Murray rdmur...@bitdance.com wrote: On Mon, 21 Mar 2011 03:44:34 +0900, Stephen J. Turnbull step...@xemacs.org wrote: I'm coming to the conclusion that those who say that Mercurial documentation should be found at the Mercurial project are wrong. I +1. I think the dev docs should explain anything needed to do the basic Python workflow, even if that feels like repeating parts of the Mercurial docs. (If it is a large chunk, then a pointer to the exactly relevant section of the Mercurial docs would be appropriate.) On the other hand, I'm not offering to do the work, so I'll happily accept what has been produced so far (thanks, Antoine!). think there's a reasonably strong case (based on the explicit promise of PEP 0374 that workflows would change as little as possible) for a follow-on informational PEP providing verbal, and maybe automated, scripts for the various operations needed in the Python workflow. Sounds good, but someone needs to write them. You'll note that I've been asking for this for a while, but as it turns out it wasn't really possible to write them correctly until we started actually using the system. I'm still not comfortable enough to write them myself, but after I've used my chosen workflow for a while I'll do my best to write it up in more detail than my earlier post as a blog post or something. I think it ought to be added to the dev guide instead of a PEP. Otherwise I agree -- the workflows are somewhat unique to Python. I personally sure haven't grokked them yet, not having done anything that required merging yet. (TBH I never got the hang of our SVN merge flow either.) -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Le 20/03/2011 02:59, Ned Deily a écrit : On a Unix-y system, here is one way to do it (no warranty on the installation instructions!): With all due respect, the instructions are overly complicated, and may also run afoul of the system conventions (sudo will put files in directories that should not be touched for example). Here’s my take: Get the code $ cd where/ever $ hg clone http://hg.python.org/hooks Edit your user ~/.hgrc of the cpython clones .hg/hgrc to enable the hook [hooks] pretxncommit.whitespace = python:/home/you/where/ever/hooks/checkwhitespace.py:check_whitespace_single Regards ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
In article 4d86be29.8070...@netwok.org, Éric Araujo mer...@netwok.org wrote: Le 20/03/2011 02:59, Ned Deily a écrit : On a Unix-y system, here is one way to do it (no warranty on the installation instructions!): With all due respect, the instructions are overly complicated, and may also run afoul of the system conventions (sudo will put files in directories that should not be touched for example). That depends on your configuration but ... Here’s my take: Get the code $ cd where/ever $ hg clone http://hg.python.org/hooks Edit your user ~/.hgrc of the cpython clones .hg/hgrc to enable the hook [hooks] pretxncommit.whitespace = python:/home/you/where/ever/hooks/checkwhitespace.py:check_whitespace_single that's *much* better, thanks! The hg documentation does not make it clear that, in the absolute path case, PYTHONPATH does not need to be manipulated, which is what I was trying to avoid. Perhaps you could add those instructions to the devguide? -- Ned Deily, n...@acm.org ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
s...@pobox.com writes: Stephen interactions across modules. That is, it's not that Subversion Stephen provided a simpler way of doing the work. Rather, it hid the Stephen fact that certain work was not being done at all. hg exposes Stephen this fact. Can you provide an example of this (real or hypothetical)? What happened to you is a real example. With svn it would go through, and any problems would be caught later. With hg, it doesn't. This is basically the statistical idea of false positives vs. false negatives. svn tends to generate false negatives (tests don't fail until after the merge), while hg tends to generate false positives (merges fail because they aren't fast-forwards). It seems to me that if all you have is unit tests it matters little, if at all, whether you catch test failures before a checkin (in your local hg repo) or after (using svn + a buildbot run). In the long run, that's right. In the short run the choice is between imposing a substantially higher burden of merging and testing on individual developers in order to get a higher quality shared branches versus imposing a detectably higher burden on the project as whole in terms of red buildbots. It clearly matters to the individual developers, and core developers are likely to have different interests here from the occasional committers. The burden on the project could get *very* high; that's why the Linux kernel went to Bitkeeper, then git, rather than Subversion. It was necessary to impose as much burden on the branches as possible before merging to trunk. But then, Python doesn't have anywhere near the change rate that the kernel does (Lennart R's woes notwithstanding). I'm not going to take a position on what's best for the Python project; I've drunk the DVCS Kool-Aid and am very much in Jesus's let's work with the tools, not against them camp. But there's an uncertain amoung of bias in that opinion, and I'm not a committer so can't speak from experience with the Python workflow. The workflow of the version control system isn't going to magically expose semantic interactions across modules. It seems to me that at best the new workflow means there is a better chance of catching textual conflicts before checkin than before. No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. Whether that is significant in practice is as yet a matter of faith for me. But again that's a personal opinion, not yet a recommendation for the project. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
hg heads showed my changeset: changeset: 68585:c63d7374b89a user:Skip Montanaro s...@pobox.com date:Sat Mar 19 09:09:30 2011 -0500 summary: Mention RFC 4180. Based on input by Tony Wallace in issue 11456. I committed. Now: changeset: 68680:64eeb4cd4b56 tag: tip parent: 68585:c63d7374b89a parent: 68679:dfceb98767c0 user:Skip Montanaro s...@pobox.com date:Sat Mar 19 09:15:28 2011 -0500 summary: commit merge The dev guide says something about collapsing changesets. Is that collapsing commits within a changeset or collapsing multiple changesets (whatever that might be)? It's only the latter. If you had a number of commits done just to implement the feature, some with commit messages such as fix typo, revert bogus change, more cleanup, etc., people don't want to see this in Python's history, so you would have to come up with a single patch for the entire feature and commit that separately. Do I need this for a trivial change? No. The essential change is in a single changeset (c63d7374b89a), which is how it should be. Can I just push at this point? Yes. If somebody pushed something else meanwhile, you'll have to merge again. Once pushed, how does it get merged into the main codebase? Pushing the change will exactly do that. Your merge (64eeb4cd4b56) has your change (c63d7374b89a) as it's parent, so 64eeb4cd4b56 now contains both the current state of cpython plus your change. If somebody else now makes other changes that succeeded your merge, you will need to merge them again, so that, at the time of your push, your most recent merge is newer than cpython's default head. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, 19 Mar 2011 09:25:07 -0500, s...@pobox.com wrote: I have a trivial little documentation patch for csv.rst. I committed it locally, then I pulled and merged: Note that if you want doc changes to appear in all the current doc sets (2.7, 3.2, dev), then you should start with patching 3.2 and merge it into default, and also patch 2.7, just like any other bug-fix commit. Making doc changes to all current doc sets is our normal practice (unless, of course, they are about new features). You can also optionally start your patching with 3.1, since the 3.1 docs will be re-generated one last time for its upcoming last bugfix release. It's easy enough (now that we no longer have to deal with svnmerge) that I've been doing that, myself. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, 19 Mar 2011 09:25:07 -0500 s...@pobox.com wrote: I have a trivial little documentation patch for csv.rst. I committed it locally, then I pulled and merged: cpython% hg pull pulling from ssh://h...@hg.python.org/cpython searching for changes adding changesets adding manifests adding file changes added 94 changesets with 422 changes to 154 files (+1 heads) 94 changesets? If you want to avoid risking conflicts, you should hg pull and hg up (or hg pull -u) before you start working on something (just like you svn up'ed before working on something). The dev guide says something about collapsing changesets. Is that collapsing commits within a changeset or collapsing multiple changesets (whatever that might be)? Do I need this for a trivial change? Can I just push at this point? Once pushed, how does it get merged into the main codebase? Sincerely, I would really recommend that you read a Mercurial tutorial. We could answer all your questions one by one but that wouldn't help you much if you don't understand the concepts. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
I have a trivial little documentation patch for csv.rst. I committed it locally, then I pulled and merged: RDM Note that if you want doc changes to appear in all the current doc RDM sets (2.7, 3.2, dev), then you should start with patching 3.2 and RDM merge it into default, and also patch 2.7, just like any other RDM bug-fix commit. Sorry, I found updating cpython hard enough. I almost gave up on just that one simple change. Anyway, I thought I was supposed to pull from head to 3.2 and 2.7. What is dev? 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote: On Sat, 19 Mar 2011 09:25:07 -0500 s...@pobox.com wrote: The dev guide says something about collapsing changesets. Is that collapsing commits within a changeset or collapsing multiple changesets (whatever that might be)? Do I need this for a trivial change? Can I just push at this point? Once pushed, how does it get merged into the main codebase? Sincerely, I would really recommend that you read a Mercurial tutorial. We could answer all your questions one by one but that wouldn't help you much if you don't understand the concepts. Skip is not alone on this one. I've been using Mercurial for a couple of months now, have read multiple tutorials and whatnot, but am still not clear on how to follow the devguide's suggested cross-branch workflow. The dance of pulling, merging, reverting, collapsing, resolving, null merging, and rebasing cross-linked branches is somewhat more involved and complex than covered in any of the tutorials I've seen. I think if we're going to require a complex workflow, then we're going to have to expect a lot of questions. And those questions shouldn't be brushed-off with go read the tutorial, we have no time for you or words to that effect. RAymond ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Antoine == Antoine Pitrou solip...@pitrou.net writes: Antoine On Sat, 19 Mar 2011 09:25:07 -0500 Antoine s...@pobox.com wrote: I have a trivial little documentation patch for csv.rst. I committed it locally, then I pulled and merged: cpython% hg pull pulling from ssh://h...@hg.python.org/cpython searching for changes adding changesets adding manifests adding file changes added 94 changesets with 422 changes to 154 files (+1 heads) Antoine 94 changesets? If you want to avoid risking conflicts, you should hg Antoine pull and hg up (or hg pull -u) before you start working on Antoine something (just like you svn up'ed before working on something). Sorry, this workflow is still new and hugely confusing to me. To make a simple edit to csv.rst I needed to do a couple pulls and merges, local commits, resolve the same conflict multiple times, get rebuffed when I first pushed because there was a tab in the file, and ask a question here. If this is the typical route necessary to make even the simplest changes which would have been a single commit with svn, my already meager rate of contributions is likely to wither away to nothing. The dev guide says something about collapsing changesets. Is that collapsing commits within a changeset or collapsing multiple changesets (whatever that might be)? Do I need this for a trivial change? Can I just push at this point? Once pushed, how does it get merged into the main codebase? Antoine Sincerely, I would really recommend that you read a Mercurial Antoine tutorial. We could answer all your questions one by one but Antoine that wouldn't help you much if you don't understand the Antoine concepts. Thanks for the snide response. If I had time to read an entire book just to learn how to do something I was doing in CVS and Subversion with no trouble, I would have done so by now. I want to understand how to use the workflow set up for this project. If you aren't willing to help me get past my initial difficulties, please don't bother responding. -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
I think if we're going to require a complex workflow, then we're going to have to expect a lot of questions. And those questions shouldn't be brushed-off with go read the tutorial, we have no time for you or words to that effect. And indeed, I think this (asking questions) is just about the only sensible way to approach this - requests to RTFM are probably less useful than people expect. The only way to learn this stuff is by doing it, not by reading about it. I think I warned that this would happen - that the tools require a large amount of relearning, and that it will take time for committers to adjust. So I'd encourage everybody to keep asking questions, and request that they are answered in a polite manner, even if the one answering thinks that the same question is already answered in some documentation. The only alternative is that some people just give up contributing to Python. I just hope that we can stick with Mercurial for more than five years, before the next hot thing comes along. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sun, Mar 20, 2011 at 5:05 AM, s...@pobox.com wrote: Sorry, this workflow is still new and hugely confusing to me. To make a simple edit to csv.rst I needed to do a couple pulls and merges, local commits, resolve the same conflict multiple times, get rebuffed when I first pushed because there was a tab in the file, and ask a question here. If this is the typical route necessary to make even the simplest changes which would have been a single commit with svn, my already meager rate of contributions is likely to wither away to nothing. Note that some of that isn't unique to the Mercurial transition (specifically, the server side hook that complained about the whitespace change existed in SVN as well). One key difference that we could historically ignore with SVN is that it would happily accept changes from an out-of-date working copy, so long as the committed changes didn't alter any files that had also been updated on the head. In practice, this *did* mean a lot of commits did get rejected, since Misc/NEWS would often conflict. Mercurial's changeset based view of the world means it wants to know how the changesets relate to each other even when they affect different files, unlike SVN which would happily do an implicit merge (creating a state in the central repo that no developer has ever tested locally). So the full flow for a trunk commit in SVN was: svn update # change stuff svn commit -m Whatever # get rejected by server side hooks (e.g. changed files, bad whitespace) make patchcheck # fix whitespace issues svn update # get updated files # Resolve any conflicts, rerun relevant tests svn commit -m Whatever Mercurial isn't really all that different, but it's distributed nature means it want to keep track of even minor things like the local whitespace fixes and the merger of your changes with the other changes that were pushed since you started work. So the example above becomes something like: hg pull -u #change stuff hg commit -m Whatever hg push # get rejected by server side hooks (e.g. changed files, bad whitespace) make patchcheck hg commit -m Fix whitespace hg pull -u hg merge # Resolve any conflicts, rerun relevant tests hg commit -m Merge with remote hg push It definitely produces some additional noise on python-checkins, since things that would normally have been resolved privately by the developer before SVN accepted the commit are now being published to the mailing list. To help with that, I've personally split my python-checkins label into two: one which contains everything from the list, and another which filters out any messages with merge in the subject line. You may also find hg outgoing useful, since that will tell you all the changesets that a call to hg push will publish, rather than just the latest changeset as shown by hg heads. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, Mar 19, 2011 at 12:55 PM, Martin v. Löwis mar...@v.loewis.de wrote: So I'd encourage everybody to keep asking questions, and request that they are answered in a polite manner, even if the one answering thinks that the same question is already answered in some documentation. Thanks. I have some basic questions. The only alternative is that some people just give up contributing to Python. I was about to do just that. :-) Now I've decided to take the plunge instead. I made a test change to the 2.5 README and merged it into 2.6 and 2.7. Then I pushed. It *seems* to have worked, but I also got some traceback: hg push pushing to ssh://h...@hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 6 changesets with 6 changes to 1 files remote: change(s) NOT sent, something went wrong: remote: [Failure instance: Traceback from remote host -- Traceback (most recent call last): remote: File /usr/lib/python2.6/dist-packages/twisted/spread/banana.py, line 153, in gotItem remote: self.callExpressionReceived(item) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/banana.py, line 116, in callExpressionReceived remote: self.expressionReceived(obj) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 514, in expressionReceived remote: method(*sexp[1:]) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 826, in proto_message remote: self._recvMessage(self.localObjectForID, requestID, objectID, message, answerRequired, netArgs, netKw) remote: --- exception caught here --- remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 840, in _recvMessage remote: netResult = object.remoteMessageReceived(self, message, netArgs, netKw) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 225, in perspectiveMessageReceived remote: state = method(*args, **kw) remote: File /data/buildbot/master/master.cfg, line 87, in perspective_addChange remote: changedict['category'] = branch_to_category[changedict['branch']] remote: exceptions.KeyError: '2.5' remote: ] remote: notified python-check...@python.org of incoming changeset 3074c77b7121 remote: notified python-check...@python.org of incoming changeset cf5e4bdb24a1 remote: notified python-check...@python.org of incoming changeset 89007356798b remote: notified python-check...@python.org of incoming changeset cc959f114739 remote: notified python-check...@python.org of incoming changeset 69650b81f4b9 remote: notified python-check...@python.org of incoming changeset 5ae4f3bbaebe I also have trouble building the 2.5 branch on OS X Snow Leopard (10.6) with Xcode 3.2 -- this is gcc 4.2.1. I think I'll just give up on that part though, it's probably just too old, and 2.7 builds just fine. I just hope that we can stick with Mercurial for more than five years, before the next hot thing comes along. +1. Just as I hope for the Python 3-4 transition, I hope that whatever comes along next has a better transition strategy. That would make it really hot. -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, 19 Mar 2011 16:32:53 -0700 Guido van Rossum gu...@python.org wrote: remote: File /data/buildbot/master/master.cfg, line 87, in perspective_addChange remote: changedict['category'] = branch_to_category[changedict['branch']] remote: exceptions.KeyError: '2.5' remote: ] That's because the buildbot notification hook tries to launch new builds on branch 2.5 but it is unknown to the buildmaster. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sun, Mar 20, 2011 at 9:32 AM, Guido van Rossum gu...@python.org wrote: +1. Just as I hope for the Python 3-4 transition, I hope that whatever comes along next has a better transition strategy. That would make it really hot. Given that the hardest part of any transition is updating developers' brains, that would be some pretty damn neat neurohacking right there :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote: On Sat, 19 Mar 2011 09:25:07 -0500 s...@pobox.com wrote: The dev guide says something about collapsing changesets. Is that collapsing commits within a changeset or collapsing multiple changesets (whatever that might be)? Do I need this for a trivial change? Can I just push at this point? Once pushed, how does it get merged into the main codebase? Sincerely, I would really recommend that you read a Mercurial tutorial. We could answer all your questions one by one but that wouldn't help you much if you don't understand the concepts. Skip is not alone on this one. I've been using Mercurial for a couple of months now, have read multiple tutorials and whatnot, but am still not clear on how to follow the devguide's suggested cross-branch workflow. The dance of pulling, merging, reverting, collapsing, resolving, null merging, and rebasing cross-linked branches is somewhat more involved and complex than covered in any of the tutorials I've seen. I think this will always be the case until someone develops a wiki-type code revision system along with a voting model. The most reliable and highest ranking code would be a nucleus whereupon all other revisions from other collaborators would revolve. Links between the revisions and the core would have acceptance requirements. All would be organized around this circular nucleus rather than attempt linearity (which not only requires a benevolent dictator, but that everyone agree so that forks do not create factions -- or worse, abandonment). That being said, it would be a radical adjustment to development style as there would no longer be a canonical or MAIN authority. But whatever, wanna help me built it? Marcos, pangaia.sf.net ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Skip wrote: Antoine wrote: 94 changesets? If you want to avoid risking conflicts, you should hg pull and hg up (or hg pull -u) before you start working on something (just like you svn up'ed before working on something). Sorry, this workflow is still new and hugely confusing to me. To make a simple edit to csv.rst I needed to do a couple pulls and merges, local commits, resolve the same conflict multiple times, get rebuffed when I first pushed because there was a tab in the file, and ask a question here. If this is the typical route necessary to make even the simplest changes which would have been a single commit with svn, my already meager rate of contributions is likely to wither away to nothing. This is reminiscent of a message on the Mercurial mailing list recently, to which I responded with a question about people experiencing problems with Mercurial because they are used to file- or directory-specific operations in other systems, eliciting this reply: hg failed saying there were uncommitted changes (his source code changes in another part of the tree). He didn't want to commit those changes yet, they weren't finished. So he was stuck. To his mind, hg was being stupid because it was getting in his way, unnecessarily linking changes in the two sets of files together. The concept of a revision being a state of the whole repo was alien. For most people that concept came in with svn. http://www.selenic.com/pipermail/mercurial/2011-March/037373.html I've spent some time trying to tidy up and improve a document on the Mercurial Wiki about CVS-like working practices with Mercurial, and this might explain the differences in operation between CVS/Subversion and Mercurial, although it doesn't yet distinguish between the narrow file-specific commits you get in systems like CVS and Subversion, and the whole-project commits you get in systems like Mercurial: http://mercurial.selenic.com/wiki/CvsLikePractice (By the time you look at that page, I might have added something, though.) I'm certainly no expert with Mercurial, and I've only been using it as a personal tool since the MoinMoin guys introduced me to it back at EuroPython 2006, so even now the right way or best practice when it comes to propagating fixes between branches/clones is something I'm still figuring out, but having lurked on the recent python-dev threads and having read various queries on the Mercurial list over the past year or so, I get the impression that reaching for things like rebase and mq as the first choice to solve various workflow problems would get some blunt criticism on the Mercurial list. That said, I can't readily find any good guides to managing a multi-branch project, but there seem to be some interesting techniques documented for some of the situations people are likely to encounter. For example: http://mercurial.selenic.com/wiki/DaggyFixes describes pulling fixes selectively which I'll probably have to try on some personal project at some point http://hginit.com/05.html describes the presumably common way of propagating fixes from stable branches to development branches Certainly, the Python devguide is a nice piece of documentation, but I feel that there's an opportunity here to address some documentation issues that would also help others using and adopting Mercurial. For example, submitting clean changes to a project (that collapse thing) is a topic for a document that could usefully be written, containing some nice diagrams that explain the mechanism to newcomers, and it would surely benefit more than just the CPython development effort. Paul ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
I made a test change to the 2.5 README and merged it into 2.6 and 2.7. Then I pushed. It *seems* to have worked, but I also got some traceback: Oops. I wouldn't have expected that tracebacks propagate that far back. This was your hg client talking to the remote hg client executing a post-push hook talking to buildbot raising an exception (for there no being builder category for 2.5). Your changesets were accepted, anyway. I also have trouble building the 2.5 branch on OS X Snow Leopard (10.6) with Xcode 3.2 -- this is gcc 4.2.1. I think I'll just give up on that part though, it's probably just too old, and 2.7 builds just fine. Yes, this is a known limitation. Please don't make any changes to the 2.5 branch unless they are security fixes (changing the copyright is fine, but I'd rather avoid even documentation changes). If you want to build the 2.5 branch, check it out from subversion. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
Am 20.03.2011 00:39, schrieb Antoine Pitrou: On Sat, 19 Mar 2011 16:32:53 -0700 Guido van Rossum gu...@python.org wrote: remote: File /data/buildbot/master/master.cfg, line 87, in perspective_addChange remote: changedict['category'] = branch_to_category[changedict['branch']] remote: exceptions.KeyError: '2.5' remote: ] That's because the buildbot notification hook tries to launch new builds on branch 2.5 but it is unknown to the buildmaster. Not exactly. It tries to categorize the changes, so that they would should up on a waterfall filtered by category. Since we have no waterfall for 2.5, I didn't add any categorization for it. This should now be fixed. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
In article aanlktiktvxsrmlw0z8ifvz3lkaedv8vui_a4f-oci...@mail.gmail.com, Nick Coghlan ncogh...@gmail.com wrote: Mercurial isn't really all that different, but it's distributed nature means it want to keep track of even minor things like the local whitespace fixes and the merger of your changes with the other changes that were pushed since you started work. So the example above becomes something like: hg pull -u #change stuff hg commit -m Whatever hg push # get rejected by server side hooks (e.g. changed files, bad whitespace) make patchcheck hg commit -m Fix whitespace hg pull -u hg merge # Resolve any conflicts, rerun relevant tests hg commit -m Merge with remote hg push As a side note, if you are prone to accidentally adding extra whitespace (like I am), you can add the whitespace check hook into your local copy of Mercurial so that you will be warned about whitespace problems immediately when you commit things to your local repos rather than later when you try to push them up to the python.org repo. You will need to add checkwhitsepace.py and reindent.py from the official hooks repo into the site-packages directory of the Python instance where your copy of hg is installed and then configure the hook in an hgrc configuration file. On a Unix-y system, here is one way to do it (no warranty on the installation instructions!): # try to avoid permission problems umask 022 hg clone http://hg.python.org/hooks cd hooks # make a dummy setup.py file for distutils cat setup.py EOF1 from distutils.core import setup setup(name='pydevhooks', version='0.1', py_modules=['checkwhitespace', 'reindent'], ) EOF1 # kludge to find the Python instance which your hg uses HGPYTHON=$(head -1 $(which hg) | sed s'/#!//') echo $HGPYTHON # install the hooks sudo $HGPYTHON setup.py install # configure the hooks in your global .hgrc file - affects all hg repos HGRC=~/.hgrc # ... or configure in specific repos #HGRC=/path/to/your_repo/.hg/hgrc cat $HGRC EOF2 [hooks] pretxncommit.whitespace = python:checkwhitespace.check_whitespace_single EOF2 -- Ned Deily, n...@acm.org ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is collapse?
On Sat, 19 Mar 2011 13:53:11 -0500, s...@pobox.com wrote: I have a trivial little documentation patch for csv.rst. I committed it locally, then I pulled and merged: RDM Note that if you want doc changes to appear in all the current doc RDM sets (2.7, 3.2, dev), then you should start with patching 3.2 and RDM merge it into default, and also patch 2.7, just like any other RDM bug-fix commit. Sorry, I found updating cpython hard enough. I almost gave up on just that one simple change. Anyway, I thought I was supposed to pull from head to 3.2 and 2.7. What is dev? That's doc speak, I guess. http://docs.python.org/dev/library, for example, points to the library reference for the docs on the default branch. -- R. David Murray http://www.bitdance.com ___ 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/archive%40mail-archive.com
