Re: [Python-Dev] We should be using a tool for code reviews
Stephen J. Turnbull step...@xemacs.org writes: Barry Warsaw writes: You can have co-located branches[1] which essentially switch in-place, so if a branch is changing some .c files, you won't have to rebuild the whole world just to try out a patch. In Mercurial these are called named branches, and they are repo-local (by which I mean they must be part of the DAG). Think of it this way: you can have several clones and when you make different commits in each, they naturally begin to diverge: clone 1: ... [X] --- [A] --- [B] clone 2: ... [X] --- [R] clone 3: ... [X] --- [U] --- [V] Though you cannot see it yet, you have created branches in the history. If you pull one clone 2 into clone 1, then the branch suddenly becomes visible in that clone -- you have two heads (B and R): clone 1: ... [X] --- [A] --- [B] \ [R] You can of course pull in clone 3 as well: clone 1: ... [X] --- [A] --- [B] | \ | [R] \ [U] --- [V] You can now use 'hg update' to switch between these three anonymous branches. You can find the three heads by using 'hg heads' or you can use the bookmarks extension to assign labels to them. These labels will move forward when you commit, just like you move a bookmark forward in a book when you read through it. Btw, you can separate such a repository again with 'hg clone -r' which lets you ask for a clone containing just a subset of another repository. You can of course also split off named branches (see below) in this way. Named branches used to have some inconvenient aspects relevant to standalone branches (they could be fairly confusing to other users if pushed before being merge to mainline). Now, named branches is sort of an extension of the above scenario. Along with the commit message, date, username, etc..., each changeset in Mercurial contains a label that tells us which named branch it belongs to. By default, changesets are on the branch called, well, default. Named branches allow you to group or namespace your changesets. For Mercurial itself, we use two named branches: default and stable. Bugfixes go on the stable branch and we do our development on the default branch. Though a named branch is a collection of changesets, you often refer to a named branch in a context where you need just a single changeset. It is then interpreted as the tip-most changeset with that branch name. So $ hg update stable will checkout the latest (tip-most) changeset on the stable branch. If you now commit a bugfix, then that changeset will also be on the stable branch since the branch name is inherited from the parent changeset. In Mercurial we then merge the stable branch back into the default branch: # fix bug $ hg commit -m 'Fixed issue 123' $ hg update default $ hg merge stable $ hg commit -m 'Merged in fix for issue123' I've written a guide to such a workflow here: http://mercurial.aragost.com/kick-start/tasks.html It's not obvious to me that Mercurial style named branches would work well here ... it would take a little thought to design an appropriate workflow, anyway. Yeah, you guys should try it out first -- it's easy to introduce named branches later if you want. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpRzl80o4Dzb.pgp 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] python-checkins
Dirkjan Ochtman dirk...@ochtman.nl writes: - http://bitbucket.org/mg/commitsigs is another extension, which takes a different tack to signing (I believe it doesn't sign the commit metadata, only the file tree, which lets it sign before the commit is finished, meaning it doesn't take up an extra cset). It does signs the complete changeset hash including the commit message, username, etc, and it does this without creating an extra changeset. This is done by computing what the changeset hash would be without an embedded signature. This hash is then signed and embedded in the changeset. This is similar to how TCP checksums are computed. This increases the size of each changeset by about 2 KB of data which cannot be compressed -- this adds up over time and I would only advice people to use the extension if they are very paranoid or have special legal requirements. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpQIiKj4dVLR.pgp 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] query: docstring formatting in python distutils code
Georg Brandl g.bra...@gmx.net writes: Am 08.07.2010 17:44, schrieb Martin Geisler: Steve Holden st...@holdenweb.com writes: Martin Geisler wrote: Stephen J. Turnbull step...@xemacs.org writes: Just ask Martin, there are too many possibilities here to worry about. If maybe we want it, and he is willing to contribute the parts he wrote to Python under Python's license, then we can worry about whether we really want it and about how much any required hoop-jumping will cost. I would be happy to relicense it under the Python license. I believe the ideal outcome, if it is possible, is for you to sign a contributor agreement. This will license your material to the PSF in such a way that we can release it under whatever license we deem necessary. Sure, I'll be happy to sign a contributor agreement if you guys think it worthwhile to use my little parser and formatter. Problem is, in the case of help() we have no way of knowing whether the given __doc__ string is supposed to be (mini)reST. Of course, reverting to showing the plain content on parsing errors is one possibility, but I can still imagine instances where something is successfully interpreted as reST, but intended to be read and understood verbatim by the author. The minirst module is actually designed to never fail: the text is first divided into paragraphs, and the paragraphs are then looked at one by one to see if they look like something more specific like a list. It's different for Hg, of course, there you can just decide that help texts have to be reST. Right, good point. At first I figured that you could also just convert the docstrings in Python, but since the help builtin is used on lots of code outside of Python this isn't really enough. -- Martin Geisler aragost Trifork -- Professional Mercurial support http://aragost.com/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] query: docstring formatting in python distutils code
Stephen J. Turnbull step...@xemacs.org writes: Benjamin Peterson writes: 2010/7/7 Stephen J. Turnbull step...@xemacs.org: Antoine Pitrou writes: http://selenic.com/hg/file/tip/mercurial/minirst.py Given that Mercurial is GPL, this is probably of no use to us, unfortunately. I must admit that reading this felt strange somehow... that a piece of open source code should be useless. But I understand what you mean :) Given that Martin apparently is the only or main author, I don't see a problem as long as he's willing. And he hasn't assigned the copyright away. (Or that the assignment has an automatic author-use-ok clause like the standard FSF assignment does, etc.) We don't assign copyright in Mercurial, so this should be no problem. This also meant that we had to contact about 300 guys when changing from GPLv2 to GPLv2+. Just ask Martin, there are too many possibilities here to worry about. If maybe we want it, and he is willing to contribute the parts he wrote to Python under Python's license, then we can worry about whether we really want it and about how much any required hoop-jumping will cost. I would be happy to relicense it under the Python license. -- Martin Geisler aragost Trifork: Professional Mercurial support http://aragost.com/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] query: docstring formatting in python distutils code
Steve Holden st...@holdenweb.com writes: Martin Geisler wrote: Stephen J. Turnbull step...@xemacs.org writes: Just ask Martin, there are too many possibilities here to worry about. If maybe we want it, and he is willing to contribute the parts he wrote to Python under Python's license, then we can worry about whether we really want it and about how much any required hoop-jumping will cost. I would be happy to relicense it under the Python license. I believe the ideal outcome, if it is possible, is for you to sign a contributor agreement. This will license your material to the PSF in such a way that we can release it under whatever license we deem necessary. Sure, I'll be happy to sign a contributor agreement if you guys think it worthwhile to use my little parser and formatter. -- Martin Geisler aragost Trifork -- Professional Mercurial support http://aragost.com/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] query: docstring formatting in python distutils code
C. Titus Brown c...@msu.edu writes: I guess docutils isn't in the stdlib (should it be?) or else we could modify 'help' to use it to prepare a straight text formatting. We're using light-weight ReST markup in the Mercurial help texts and transform it into straight text upon display in the terminal. We want no external dependencies for Mercurial, so I wrote a mini ReST parser in about 400 lines of code. It cheats a lot and can only handle simple constructs... but maybe it would be interesting for Python's help? You find it here: http://selenic.com/hg/file/tip/mercurial/minirst.py Its test and the corresponding output shows the markup it can parse: http://selenic.com/hg/file/tip/tests/test-minirst.py http://selenic.com/hg/file/tip/tests/test-minirst.py.out It would of course be much nicer to have Docutils in the standard library. I'm not a Docutils developer, but to me it seems that Docutils is now a very stable and widely used package, so it would IMHO make sense to include it. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpf0R31gMZHO.pgp 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] Mercurial migration readiness
Martin v. Löwis mar...@v.loewis.de writes: My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently: This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch? IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway). I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required? You don't -- it is tempting to think of a named branch as a kind of container for changesets, but that metaphor makes people think that you can put changesets into a named branch and takes them out again. The opposite is in fact true: the changesets induce the named branch. Each changeset has a field in its metadata that names the branch it is on. So if you do hg branch X hg commit -m Created X branch then the newly created changeset has branch=X in its metadata. The X branch has thus been created because of the changeset. If there are no changesets with branch=X in your repository, then there is no X branch. A named branch is thus more a labeling system -- changesets belonging to the branch can (in principle) be scattered all over the repository. They are normally a connected sub-graph, though, and Mercurial will complain if you try to re-start a branch name. Since the branch name is embedded into the changesets themselves, you cannot changeset it without changing the identities of the changesets. A branch appears in the output of 'hg branches' if there are any open branch heads (a branch head is a changeset with no children on the same named branch). Use the 'hg commit --close-branch' command to make a closed branch head. The branch is considered closed when it only has closed branch heads. Summing up, the notion of named branches correspond quite closely to how people model branches in Subversion: if you make your changes in the directory branches/X/, then we say you work on the X branch. These revisions will always be on that branch. You can delete the branch by deleting the directory from the HEAD revision. The changes remain in the history and even after merging with trunk/, the old revision will of course show that they were made in the branches/X/ directory. Take a look at the bookmarks extension if you want to work with un-named branches (often called anonymous branches) instead. These branches are just a fork in the history graph, but they have no permanent name. The bookmarks gives you a convenient way to refer to them. Without bookmarks you can of course look at 'hg heads' or some other log viewer. http://mercurial.selenic.com/wiki/BookmarksExtension Since Mercurial 1.6, you can push and pull the bookmarks between repositories. They used to be local only, but this is now solved. See the bottom of the wiki page. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpocrujdNlzx.pgp 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] Mercurial migration readiness
Éric Araujo mer...@netwok.org writes: I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be hg merge otherbranch. Subsequently committing the merge (after fixing conflicts) creates a new changeset on the current branch. Indeed, merges are branch-wise operations, not changeset-wise. You need tricks to copy one changeset from a named branch into another one. You basically need to replay the changes -- the transplant extension can do this for you. This is more or less a wrapper around 'hg export' (gives you a diff) and 'hg import' (applies the diff). Copying changesets between a stable branch and a devel branch is easy if the devel history is a strict superset of the stable history. Every changesets landing into stable can then just be pulled into devel. This means no different named branches for stable and devel. Not sure I’m clear enough, I hope Mercurial experts can chime in. It sounds like you are describing how Mercurial itself was developed before we began using named branches. This part of the graph is typical for us then: http://selenic.com/repo/hg/graph/52c5be55af82 Notice the three merges wtih 'crew-stable', which was what we called the clone representing the next stable release. Whenever a bugfix is made, it is immediatedly merged into the 'crew' clone, where normal development takes place. This gives a characteristic flow with two tracks (branches), where one is continuously merged into the other. The two with commit message Fix typeerror when specifying both --rebase and --pull (dd1b47e17d7e and aee8455ee8ec) are a typical example of a transplanted changeset: the bug was first fixed in 'crew', but it was then realized that it should also be in the 'crew-stable' repository so that it could be part of the next point release. Today we use a 'stable' branch in addition to the 'default' branch and the graph looks much the same: http://selenic.com/repo/hg/graph/4d3288197717 You'll notice the small labels saying 'stable' on the changesets from that branch -- that is the whole difference. A named branch is made up by the changesets that same the branch name, but the graph itself works the same. The nice thing about our current setup is that I can do hg update stable and the name 'stable' is then interpreted as the tip-most changeset on the stable branch. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpupOqXXRTQp.pgp 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] Mercurial migration readiness
Stephen J. Turnbull step...@xemacs.org writes: anatoly techtonik writes: To be prepared for conflicts I review code with `svn log -vr base:head` before updating. But with Mercurial I see two major problems with my workflow (which I am unlikely to change for the next few weeks due to heavy automation): 1. No shallow checkouts - that means that I have to copy 200Mb+ for every patch I have No, you don't. You make links to 200MB+ (unless you're on Windows, where I don't know how this works). Surprisingly, it works there too due to NTFS hardlinks :-) This is much cheaper than copying, though not as cheap as in git. I don't hesitate to make branches in Mercurial. You can have branches inside your repository with Mercurial too, just like in Git. The bookmarks extension is for that. With Mercurial 1.6, you can push and pull bookmarks -- they are no longer local-only. I may work more sequentially than most, but I do all my work on Mercurial using a single clone. 3. There is no clear branch separation in my working copy. I don't know how to diff files in different branches without copying 200Mb+ clone. I don't know how to diff my files with remote repository without pulling it. If you're at all serious about working with Mercurial, you don't do any operations except pull (and push, if you're a committer) against the remote. You keep a local pristine mirror of the remote repository, which you update frequently, and all of your work revolves around that rather than around contact with upstream. This does mean that when upstream uses a repo-per-branch model you have to keep multiple mirrors. On the other hand, you can work directly in branches that you work on only infrequently, and also use Mercurial queues to avoid making branches if you don't want to. That is one option and I think The Definitive Guide advocates it. However, you are free to mix the upstream clones into a single clone if you want (with 'hg pull' from different upstream repositories), or you can keep them separate. If the upstream uses a single repository with multiple named brancehs, then you can still maintain separate clones locally, say one per named branch (with 'hg clone http://...#branch' style clones). There is really no contraints on how you can setup your local repositories. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpNKiuQQV5DV.pgp 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] PEP 385 progress report
Dirkjan Ochtman dirk...@ochtman.nl writes: Hi everybody! I hope you have fun at PyCon :-) As for the current state of The Dreaded EOL Issue, there is an extension which seems to be provide all the needed features, but it appears there are some nasty corner cases still to be fixed. Martin Geisler has been working on it over the sprint, but I think there's more work to be done here. Anyone who wants to jump in would be quite welcome (maybe Martin will clarify here what exactly the remaining issues are). I'm sorry about the delay in my response -- but things have now finally moved forward after Benoit Boissinot (another Mercurial developer) looked at things. With the most recent fixes pushed to the eol repository[1], I can no longer break the tests by running them repeatedly in a loop. In other words, they finally appear to be stable. I feel this would be a good opportunity for people to begin testing the extension again. It seems that people has not done that so far, or at least we haven't gotten any feedback in a long time. It is now easier to test than before since changes to the .hgeol file is picked up immediatedly without it being committed. This means that you can enable eol (in .hg/hgrc, say) and play around *without* affecting others who use the repository. When you change patterns in .hgeol, you'll see the effects in the output of 'hg status' -- files that will be updated on the next commit appear modified. My dissertation is due this Friday(!), so I will not have much time to look at EOL issues this week (as usual). But please give it a spin anyway and let us hear what you think! [1]: http://bitbucket.org/mg/hg-eol/ -- Martin Geisler pgpQwH8TBxAhw.pgp 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] Google Groups Mirror
anatoly techtonik techto...@gmail.com writes: What is the point in maintaining archive listed in http://mail.python.org/mailman/listinfo/python-dev if it is not searchable? Recently I needed to find old thread about adding tags to roundup but couldn't. GMane archive doesn't search - http://news.gmane.org/navbar.php?group=gmane.comp.python.develquery=roundup+tags This is where your search should go: http://search.gmane.org/?query=roundup+tagsgroup=gmane.comp.python.devel I got the page when searching from http://dir.gmane.org/gmane.comp.python.devel I don't know why the search box at the bottom of http://news.gmane.org/gmane.comp.python.devel fails... -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpepIKXk53zy.pgp 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] transitioning from % to {} formatting
Raymond Hettinger pyt...@rcn.com writes:
[Steven Bethard]
. Just saying ok, switch your format strings
from % to {} didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users get any say in this?
I'm a user! :-)
I hate calling methods on string literals, I think it looks very odd to
have code like this:
Displaying {0} of {1} revisions.format(x, y)
Will we be able to write this as
Displaying {0} of {1} revisions % (x, y)
too?
I imagine that some people are heavily invested in %-formatting.
Because there has been limited uptake on {}-formatting (afaict), we
still have limited experience with knowing that it is actually better,
less error-prone, easier to learn/rember, etc. Outside a handful of
people on this list, I have yet to see anyone adopt it as the
preferred syntax.
I've skimmed over the PEP, and the new {}-syntax seems to have some nice
features. But I've not seen it used anywhere yet.
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
pgpWsgnx0JNG6.pgp
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] Mercurial migration: help needed
Antoine Pitrou solip...@pitrou.net writes: Le samedi 05 septembre 2009 à 15:19 +0200, Martin v. Löwis a écrit : In addition, a DVCS brings in another problem dimension: when people push their changes, they have *already* committed them - and perhaps not even they, but a contributor from which they had been pulling changes. The bogus change may have been weeks ago, so the subversion solution (of rejecting the commit to happen) doesn't quite work that well for a DVCS. I don't think this problem is really serious. If the push fails, you can just commit (locally) a new changeset that repairs the EOL or indentation problems, and push the whole bunch of changesets again (I assume the server-side hook will not examine changesets individually, but only the last of them?). Yes, the server-side hook will have to work like this in order for people to fix mistakes like you just described. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpJVx1LcPK63.pgp 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] Mercurial migration: help needed
Martin v. Löwis mar...@v.loewis.de writes: I don't think this problem is really serious. If the push fails, you can just commit (locally) a new changeset that repairs the EOL or indentation problems, and push the whole bunch of changesets again (I assume the server-side hook will not examine changesets individually, but only the last of them?). Yes, the server-side hook will have to work like this in order for people to fix mistakes like you just described. Not necessarily. People could also be required to go back and replay all changes. Replaying changes, i.e., editing history is quite easy as long as you have done no merges. So people can indeed fix their mistakes by cleaning up history as long as they have a linear history. Both mq and histedit are available for this: http://mercurial.selenic.com/wiki/MqExtension http://mercurial.selenic.com/wiki/HisteditExtension The problem comes if a small group have been working together on a new feature and have merged changes in from the mainline while doing so. They will then no longer be able to edit past the most recent merge. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpaLCBp1jBUE.pgp 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] hgeol extension
Martin v. Löwis mar...@v.loewis.de writes: Can anyone (re-) post the specification of the proposed extension, to the level that it is currently defined? For reference, here are the original specification, mine and Martin Geisler's: http://mail.python.org/pipermail/python-dev/2009-August/090984.html http://mail.python.org/pipermail/python-dev/2009-August/091453.html Here is my attempt at summarizing it: - name of versioned configuration file (in root of tree): .hgeol - names of conversion modes: native, LF, CRLF In the configuration file, there is a section [patterns] which maps file name patterns to conversion modes, e.g. [patterns] **.txt = native **.py = native **.dsp = CRLF **.bat = CRLF Tools/bgen/README = native Lib/email/test/data/msg_26.txt = CRLF - Martin Geisler also proposes that there is a section [repository] native = conversionmode I personally feel YAGNI; it should only support LF (adding such a feature later may be considered) I don't think it's a good idea to store everything in LF in the repository. Unlike Subversion, you cannot expect all interactions to take place through the eol-filter we're implementing. Letting people checkout a useful unfiltered clone would be possible if we know the repository native format and convert back to that. Anyway, it's a minor detail. More importantly, I've posted a simple, rough extension that does this here: http://markmail.org/message/yj4so736t4cfdulv I figured it would be better to discuss the design and implementation on mercurial-devel since there are more Mercurial hackers there. I've CC'ed a bunch of people from this thread to seed the discussion -- the rest of you on python-devel are hereby invited to join :-) http://selenic.com/mailman/listinfo/mercurial-devel -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpgBUTv4WZGB.pgp 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] Mercurial migration: help needed
Martin v. Löwis mar...@v.loewis.de writes: So the extension should do that: either abort commits with the wrong EOL markers or do as Subversion and automatically convert the file in the working copy. Maybe I misunderstand: when people use the extension, they cannot possibly make mistakes, right? Because the commit that gets aborted is already the local commit, right? Of course, it may still be that not all people use the extension. Exactly, when people use the extension, they wont be able to make bad commits. I think this is of concern to Mark (and he would like hg to refuse operation at all if the extension isn't used), but not to me: I would like this to be a feature of hg eventually, in which case I don't need to worry whether hg enforces presence of certain extensions. Yes, that would be nice for the future. I don't know if the other Mercurial developers will see this as a big controversy -- Mercurial has so far made very sure to never mutate your files behind your back. Expansion of keywords (like $Id$) is also implemented as an extension. If people make commits that break the eol style, we could well refuse to accept them on the server, telling people that they should have used the extension (or that they should have been more careful if they don't use the extension). Indeed. Their work will not be lost -- one can always take the final file, convert the line-endings, copy it into a fresh clone and commit that. With more work one could even salvage the intermediate commits, but that is probably not necessary. I think subversion's behavior wrt. incorrect eol-style is more subtle. In some cases, it will complain about inconsistencies, rather than fixing them automatically. Okay --- I don't have much experience with the svn:eol-style, except that I've read about it in the manual. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpaYHbx5rh2L.pgp 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] Mercurial migration: help needed
Stephen J. Turnbull step...@xemacs.org writes: Mark Hammond writes: [extensions] required_for_commit = win32text,some_other_ext That might require a change to hg's ini file semantics if currently it refuses to parse [extension] sections in versioned hgrcs. It doesn' refuse anything like that. When Mercurial starts, it reads these configuration files: http://www.selenic.com/mercurial/hgrc.5.html#files Notice that they are all outside the clone's working directory, the closes one is the repo/.hg/hgrc file. As I wrote somewhere else in this thread, you can add %include ../.repo-settings in your repo/.hg/hgrc file, and this will result in repo/.repo-settings being loaded (and this file *is* in the working copy and can thus be put under revision control). -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpmaXyOsnq7C.pgp 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] Mercurial migration: help needed
Stephen J. Turnbull step...@xemacs.org writes: Mark Hammond writes: On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: Possibly - although I would expect the existing section names be reused when applied to a versioned file, I'd be more than happy for the hg guys to declare new names are appropriate for this. If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules. There is a [decode] and an [encode] section: http://www.selenic.com/mercurial/hgrc.5.html#decode-encode The win32text extension works by defining new filters which can then be used like this: [encode] ** = cleverencode: [decode] ** = cleverdecode: (they are clever because they skip binary files) True, but how many people will just download the extension and enable it? In the ideal world, exactly as many people who would read the Python developer guide, then download and install the extension based purely on that. IOW, it is Python itself setting the policy, so people need to make their own decisions based on that, regardless of whether the tool enforces it or not. You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by social engineering, and why I worry about policy pushback from Mercurial HQ. Maybe that's more paranoid than they are But it can't hurt your cause to be ready for that kind of worry. Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpAl8dMJYc9u.pgp 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] Mercurial migration: help needed
Paul Moore p.f.mo...@gmail.com writes: 2009/8/22 Martin Geisler m...@lazybytes.net: Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip So, is the implication therefore that there would be resistance to having some way of making a setting which *is* copied on clone, which says that you can't commit in this repository unless you have the following extensions enabled? It sounds somewhat invasive to forbid commits. Moreover, repository owners should remember that clients can do whatever they want, so this can only be a hint, never a requirement. I don't think this has been mentioned: When you clone you move history (changesets) only and I'm pretty sure you cannot even read the configuration settings over the wire protocol. So cloning from a HTTP URL wont copy a setting found in the repo/.hg/hgrc file. This implies that the settings should live in a version controlled file. I think that is sensible under all circumstances. So if the win32text extension (horrible name, I agree... it should have been made more general and called eolconvert or something like that) would just read a configuration file from the repository, then all you should ask people is to enable win32text. Or is the fact that it's only saying you must have an extension called win32text enabled and not actually enabling code directly, sufficiently secure to make it acceptable? It is definitely secure enough to be included. There should be a way to turn off those hints, though: I might want to clone the Python repository and play around with it without enabling win32text. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgp94ixQNXvhg.pgp 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] Mercurial migration: help needed
Dj Gilcrease digitalx...@gmail.com writes: On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote: Enabling extensions in a versioned file is not going to fly. any specific reason? In the general case, you can specify an extension to be enabled by filename: [extensions] foo = ~/src/foo So if I can enable an extension like that on your system, I might be evil and commit a bad extension *and* enable it at the same time. You might argue that one should then limit which extensions one can enable in a versioned file, but it seems hard to come up with a good mechanism for this. The current mechanism is the users own ~/.hgrc file which can be seen as a whitelist of extensions he trust. An alternative could be the new %include syntax for configuration files, which was introduced in Mercurial 1.3. If you add %include ../config to your .hg/hgrc file, the (versioned!) file named 'config' from the root of your repository will be included on the spot. The catch is that you have to add such a line to all your Python clones. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpFj5YhluRNP.pgp 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
