Re: [core-workflow] bugs.python.org-related GSoC project
On 03/16/2015 03:06 PM, Ezio Melotti wrote: Pierre-Yves David (one of the Mercurial devs) has been working on a >Mercurial extension for that at >https://bitbucket.org/ncoghlan/cpydev/src/default/cpyhg.py?at=default > >He's hoping to spend more time on it soon so folks will have something >to try out at the PyCon sprints, so I wouldn't bet on this idea still >being around as a candidate project by the time GSoC rolls around. > I'm not sure if Brett was suggesting to do this on the client side (i.e. a tool used by committers on their machines) or something on the b.p.o side since both have been considered and discussed in the past. If it's aimed to committers/contributors (like the one Nick linked) then we have to see if people wants something similar. Personally I find importing a patch from the tracker (hg imp --no-c url_of_the_patch), running the tests (./python -m test), and committing it (hg ci -m "message") trivial, so I would have little use for this tool. I might find it more interesting if it allowed me to post patches to bpo without having to save a .diff and upload it manually, or if it had some kind of interaction with the other tools that we will use. The idea here is to have a very simple extension talking to roundup and allowing: - apply latest patch from an issue `hg cpy-get ` - upload patches to an issue `hg cpy-put ` (I've not strong opinion on command names) The first one (get) is really easy to do and will reduce the overhead of looking at a patch. The second one is not hard either as long as we have the appropriate API roundup side. For about a year, I've been using one line command to fetch and submit series of patches for the Mercurial project itself and it is really convenient. I gave a small look at the tool again this monday but got blocked by permission issue on the current API (did not spend too much time to look at it) Cheers, -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] the Misc/NEWS problem
On 08/05/2015 10:30 PM, Brett Cannon wrote: If we ever want to have a nice workflow where we can automate as much as possible, we need to figure out a way deal with our most common merge conflict: Misc/NEWS. Thanks to shifts in the format between different minor versions the file is pretty much guaranteed to have a conflict when doing a merge up a version. So how do we solve this? I can remember 3 possible solutions that have been proposed previously: 1. A single file per entry 2. A single file per release version of Python 3. Automating it based on commit messages I personally prefer #3 as I hate repeating myself since I just copy and paste the first line(s) of my commits to Misc/NEWS as it is anyway (basically up to the first pair of newlines). We would need a way to signal that the commit message contains nothing useful for the to-be-generated NEWS file when it's simply a fix for a previous commit (probably some marker that is somewhat inconspicuous like a dash on its own line or something). In terms of the section of the NEWS file that a commit belongs, that can once again be a marker or honestly something we drop or infer based on what files were edited in the commit. (I'm a bit late to the party here, sorry). You have another solution (5) having a dedicated merge script for misc/NEWS that knows how to parse the format and generate a good merge. It should not be too complicated to achieve. I've successfully used such script for similarish file in the past. The main issue of (3) is that you will make mistake. Either wrong commit message or change flagged as News worthy but later backed out or changed so much than the initial message is irrelevant. (Mercurial will have not problem editing commit message as long as they did not made it to the main public repo, however be sure that you will let mistake slip through). -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
[core-workflow] Mercurial Sprints
Greeting, Python people, The mercurial community gather twice in the next 2 months, some of you might be interested to attend. It would be a good opportunity to share use case, paint point and get some bug squashed. This thursday, we'll have a minisprint in San Francisco: - https://mercurial.selenic.com/wiki/201509MiniSprintBayArea From October 23th to 25th we'll have a bigger, global sprint in London: - https://mercurial.selenic.com/wiki/3.6sprint See you there ;-) -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Help needed: best way to convert hg repos to git?
On 02/06/2016 01:57 AM, Brett Cannon wrote: https://www.python.org/dev/peps/pep-0512/#define-commands-to-move-a-mercurial-repository-to-git There appear to be multiple ways to convert hg repos to git, but no clear winner. It would be great if some one/people took on the task of evaluating the tools available out there by converting the cpython repo and seeing which one has the best results. We, at Facebook, have been happily using hg-git in production for bidirectional conversion of repositories of insane sizes. I would look in that direction for your conversion. -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Help needed: best way to convert hg repos to git?
On 02/12/2016 02:37 PM, Senthil Kumaran wrote: Hi Pierre, Do you have external documents that you could point us to so that it help us with the research? Thanks for sharing this detail on hg<->git already working for a huge repo. I would expect the hg-git documentation to be the place to start. -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Help needed: best way to convert hg repos to git?
On 02/13/2016 02:56 AM, Nick Coghlan wrote: On 13 February 2016 at 11:15, Brett Cannon wrote: I don't remember the story behind cpython-fullhistory, but it's obviously incomplete since just stopped post conversion. You will need to find someone who knows (I'd ask on python-dev). Also realize that this will be our fourth VCS (cvs, svn, hg, now git). This is not going to be a perfect history of the semantic actions of commits from the beginning of time just due to the fact that these VCS tools all use different concepts. There's also the fact that prior to the move to SourceForge in 2000, all changes had to be funneled through the half dozen or so people with write access to the CVS tree: https://docs.python.org/3/whatsnew/2.0.html#new-development-process I think it's definitely OK if future code archaeologists need to dig into the SVN repository to get a more complete view of CPython's history. I've never met a project who did not regret such decision at some point. Keeping older history is usually valuable. Mercurial have powerful enough tool to let you get all the history back together, I assume git probably have that power too. This is your call, but I strongly recommend taking advantage of this migration to put everything back together. -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Re: [core-workflow] Help needed: best way to convert hg repos to git?
On 02/15/2016 10:12 AM, Petr Viktorin wrote: On 02/14/2016 06:24 PM, Pierre-Yves David wrote: On 02/13/2016 02:56 AM, Nick Coghlan wrote: On 13 February 2016 at 11:15, Brett Cannon wrote: I don't remember the story behind cpython-fullhistory, but it's obviously incomplete since just stopped post conversion. You will need to find someone who knows (I'd ask on python-dev). Also realize that this will be our fourth VCS (cvs, svn, hg, now git). This is not going to be a perfect history of the semantic actions of commits from the beginning of time just due to the fact that these VCS tools all use different concepts. There's also the fact that prior to the move to SourceForge in 2000, all changes had to be funneled through the half dozen or so people with write access to the CVS tree: https://docs.python.org/3/whatsnew/2.0.html#new-development-process I think it's definitely OK if future code archaeologists need to dig into the SVN repository to get a more complete view of CPython's history. I've never met a project who did not regret such decision at some point. Keeping older history is usually valuable. Mercurial have powerful enough tool to let you get all the history back together, I assume git probably have that power too. This is your call, but I strongly recommend taking advantage of this migration to put everything back together. While "putting everything back together" would be great, it doesn't *have* to block the migration. Git has a command called "git replace" that lets you do this later. The Linux kernel (which switched to Git before Git migration tools existed) has a separate "early history" repo that you can "prepend" to the main one. Then, in your local copy, it looks like one unbroken history. Since Git commits are snapshots and not deltas, this works amazingly well -- it's just telling Git's object retrieval routine to retrieve instead of . The disadvantage is that it has to be done in each clone individually -- no one can rewrite history for others. Two commands every future historian would have to do: git fetch git replace --graft While this exists, I believe this would be much more convenient to have the history right in the first place. But that's not my call. -- Pierre-Yves David ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
