Ezio Melotti added the comment:
I created #17570 about the Windows-related improvements, so this can finally be
closed.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 7a707540391e by Ezio Melotti in branch 'default':
#14468: add FAQs about merge conflicts, null merges, and heads merges.
http://hg.python.org/devguide/rev/7a707540391e
--
___
Python tracker
Changes by Ezio Melotti ezio.melo...@gmail.com:
Removed file: http://bugs.python.org/file29394/issue14468-new-faqs.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
The attached patch fixes the typo and mentions ``hg heads branch``.
I think a version of your 6 step display would be helpful. It was for me.
The FAQ already describes the general approach (merge heads in each branch and
then merge branches as usual). The
Ezio Melotti added the comment:
The attached patch adds 3 new FAQs:
* How do I solve merge conflicts?
* How do I make a null merge?
* I got abort: push creates new remote heads! while pushing, what do I do?
It also replaces the overly generic How do I find out which revisions need
merging?.
Terry J. Reedy added the comment:
For the null merge entry, /filed/files/.
The create new remote heads. is really needed. I handled a situation wrong
again today. Question: commit to 3.2, merge forward without change, push, and
message is '... new remote head in 3.2'. Is 3.2 really the only
Ezio Melotti added the comment:
Question: commit to 3.2, merge forward without change, push, and message is
'... new
remote head in 3.2'. Is 3.2 really the only branch with a head conflict?
I don't remember the details of the error message, but you can use hg heads
to verify that. In
Terry J. Reedy added the comment:
I now understand what I should have done. After pulling and updating,
1. Make sure there is only 1 head per branch by using 'hg heads branch*.
Merge all but only pairs revealed by that command.
* 'hg heads' without giving a branch lists all heads in all
Roundup Robot added the comment:
New changeset 50e726533391 by Ezio Melotti in branch 'default':
#14468: move a paragraph and link to the list of branches.
http://hg.python.org/devguide/rev/50e726533391
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
Yes, it should be added back in the FAQs.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Chris Jerdonek added the comment:
Ezio, did you delete the section on null-merging in your commits? I don't see
it in the devguide anymore.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
Ezio Melotti added the comment:
I went through all the messages on this issue, and I'll address them here.
There's enough material for two new issues (advanced FAQs, and improvements
about Windows docs), and a few minor issues that can be discussed and fixed as
part of this issues before
Antoine Pitrou added the comment:
I haven't really followed the discussion here, but both patches look ok to me
(the committing.rst one, especially, is a welcome cleanup).
--
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
I still fail to understand what are you trying to achieve.
My goal is to reach consensus on changes and have them committed. In its
current form, I don't agree with the patch. The length of the comment thread
and the length of the patch has discouraged me
Nick Coghlan added the comment:
Perfect is the enemy of good. I vote for just committing it, then Chris can
propose additional fixes/changes in a subsequent patch.
On 26 Feb 2013 09:52, Chris Jerdonek rep...@bugs.python.org wrote:
Chris Jerdonek added the comment:
I still fail to
Ezio Melotti added the comment:
Perfect is the enemy of good. I vote for just committing it, then
Chris can propose additional fixes/changes in a subsequent patch.
Agreed.
Chris, any preference about the number of commits (8 separate commits, 1-6 +
7-8, 2 on its own)?
--
Chris Jerdonek added the comment:
For the record, I don't recall *any* changes being made to any of the patches
in response to mine or others' comments, other than dividing them up. So we're
not talking about perfection. If they're going to be committed as is, it might
as well be one patch.
Ned Deily added the comment:
ISTM, committing changes to the devguide is fundamentally different from
committing a change to Python itself. The devguide has a much smaller and
focused audience, does not have compatibility considerations, it's continuously
releasable etc etc. So there's no
Ezio Melotti added the comment:
OK, I'll commit 1-6 and 7-8 then. After that we can further improve things
starting from there.
it would be easier to get meaningful additional review after the
current set of changes are committed rather than continually redoing a
large set of patches.
Chris Jerdonek added the comment:
But, surely at this point, it would be easier to get meaningful additional
review after the current set of changes are committed rather than continually
redoing a large set of patches.
This was my reason for asking early on that the changes be proposed and
Ezio Melotti added the comment:
This was a somewhat major rewrite. The fact that we had no rietveld available
made things more complicated on the reviewer side, and splitting the patch in
smaller chunks made things more complicated on my side.
FWIW I have 2 major doc issues up next: #4153
Roundup Robot added the comment:
New changeset a50e537c5914 by Ezio Melotti in branch 'default':
#14468: document the use of the share extension as the suggested approach for
core developers.
http://hg.python.org/devguide/rev/a50e537c5914
New changeset 3e213eaf85a6 by Ezio Melotti in branch
Terry J. Reedy added the comment:
While multiple, spaced, commits might have been better, if the first had been
made at least 6 months ago, I agree that the best thing *now* was to commit
these as a base for further improvements. There are 19 other open devguide
issues to review and close as
Ned Deily added the comment:
I think the core-mentorship list would be one place to get more opinions if
more are needed.
Keep in mind that the core-mentorship list is a closed list so any discussions
there would take place without direct participation of the (many?) core
developers, like
Terry J. Reedy added the comment:
I have no intention of excluding you ;-). Please comment on any or all of the
other 19. But if an issue is stuck with inadequate or conflicting developer
opinion, getting supplemental opinions from target users, as in There is a
proposal to change 'abc' to
Chris Jerdonek added the comment:
As discussed above and because this comment thread is getting very long, I'm
going to start proposing smaller issues off of this one. In this way we can
start committing as we reach agreement, and hash out any disagreements in more
focused contexts around
Ezio Melotti added the comment:
I'm going to start proposing smaller issues off of this one
I still fail to understand what are you trying to achieve. If you want to
further dissect my patches, hand picking chunks and reorder them in order to
obtain even more patches, I'll just close this
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
hgrepos: -170
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
Removed file: http://bugs.python.org/file28628/issue14468-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Removed file: http://bugs.python.org/file28629/committing.rst
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Removed file: http://bugs.python.org/file28540/issue14468.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29143/2-move_two_sections.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file:
http://bugs.python.org/file29144/3-update_active_branches_and_mergin_order.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29148/7-move_faq_in_two_subsections.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29142/1-add_clones_setup.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file:
http://bugs.python.org/file29145/4-update_merge_within_same_version.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file:
http://bugs.python.org/file29146/5-update_merge_between_major_versions.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29149/8-update_faqs.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29147/6-remove_outdated_sections.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29151/7-8-faqs.rst.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file29150/1-6-committing.rst.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
I extracted the diffs and attached them to the issue.
The first 6 patches update committing.rst:
[1]:
https://bitbucket.org/ezio_melotti/devguide-14468/commits/c2fca99bdb7212c4815d9fe6b0c869bb4358886a
[2]:
Chris Jerdonek added the comment:
Thanks for waiting and for posting the patches here. I think the second patch
2-move_two_sections.diff should be committed now, along with making Working
with Mercurial a higher-level header (as it is done in the aggregate patch).
This will separate the
Terry J. Reedy added the comment:
Looking at patch 1. On Windows, ~/.hgrc is $HOME$/mercurial.ini.
On my win7 machine, that translates to C:/Users/Terry/mercurial.ini.
I think it would be different on xp. But with TortoiseHG/Workbench, one should
better use the Settings dialogs than edit
Ezio Melotti added the comment:
I could mention mercurial.ini too, but I don't think the devguide should cover
tortoisehg. All the commands should work fine on Windows too.
I don't think that is actually used as I created the clones with
hg update rather than hg share.
Do you you mean
Chris Jerdonek added the comment:
For reasons I stated above, I think it will help to break this issue into
smaller, self-contained parts as we go -- even if some of the issues turn out
to be short-lived.
For example, an issue can be created for adding to the docs a section on how to
set up
Ezio Melotti added the comment:
The current 1-add_clones_setup.diff patch mixes things by including
info on applying, committing, and merging a patch under the section on
setting things up.
The goal of that section is to provide an overview of all the steps that a
committer has to follow,
Terry J. Reedy added the comment:
Do you you mean s/update/clone/? duh, yes
I don't think the devguide should cover tortoisehg.
Given the obnoxiousness of Command Prompt, and how foreign it is to working on
Windows, I think maybe there should be an addendum *somewhere*, but I don't
expect
Chris Jerdonek added the comment:
The Clones setup section is not about how to set up a clone, but how do
I do these steps depending on the specific setup I'm using (single or
multiple clones).
Then the section should be called something like Cloning approaches rather
than Clones setup.
Terry J. Reedy added the comment:
As someone who previously tried but failed to setup shared clones, to avoid the
apparently senseless copying of multiple copies of .hg/store, because of the
inadequate disjointed doc, I like patch 1. I am using it now to redo my setup
and batch file. I think
Ezio Melotti added the comment:
I think it would be good to have a separate subsection dedicated just
to the setting up portion of multiple clones with the share extension
I'm not sure that's necessary though, given how simple it is (enable share
extension, hg share source dest, repeat).
Terry J. Reedy added the comment:
I meant one pull and multiple updates (instead of the multiple 'pull -u's I
have now).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Éric Araujo added the comment:
Let’s stay friends here :) Why not remove the existing patches here, export
the 8 changesets as patches, attach them here, let people comment? (I’m not
keen on having discussion outside of our system)
--
___
Python
Ezio Melotti added the comment:
Because this is a patch for the devguide, so we cannot use Rietveld for the
review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
If there are no comments I'll commit this during the weekend.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Chris Jerdonek added the comment:
I would like to request again that these changes be proposed and committed in
smaller chunks.
I have comments of a basic nature that would be much easier to discuss and
address in the context of smaller patches. Otherwise, the discussion isn't
manageable
Ezio Melotti added the comment:
On the repo I created (https://bitbucket.org/ezio_melotti/devguide-14468) there
are separate commits that include smaller changes. The patches attached to
this issue are outdated.
--
___
Python tracker
Chris Jerdonek added the comment:
My understanding is that the commits are all or nothing. In other words, they
all need to be reviewed before any are committed. I would like for the patches
to be reviewed and committed individually so the review process is more
manageable and people can
Chris Jerdonek added the comment:
Also, I would be happy to start that process using the work that you have done.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
Yes, I was planning to collapse them in a single patch and push only that. I
don't think they can be further divided. In the moment I add the paragraph
about setting up the multiple repos using hg share the old description
becomes unnecessary, the
Chris Jerdonek added the comment:
I see ways that the changes can be proposed and committed incrementally. I can
start proposing those.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
Ezio Melotti added the comment:
I'm not sure what's the point though. The repo on bitbucket provides an easy
way to review individual changes, and pushing everything at once prevents
history pollution (assuming you consider 8 related changesets as pollution).
That's similar to the process
Chris Jerdonek added the comment:
The point is to allow a manageable discussion to take place around points of
contention while making forward commit progress along the way. I have
suggestions right now, but the current massive batch of changes makes it too
unwieldy. The incremental commits
Ezio Melotti added the comment:
The point is to allow a manageable discussion to take place around
points of contention
That can be done as (possibly inline) comments on bitbucket on the individual
commits.
while making forward commit progress along the way.
I'm not sure how you intend
Ezio Melotti added the comment:
I now divided and regrouped the FAQs in two sections, one for everyone and
one for core developers.
I'm not sure what to do with the long-term development of features section.
One one hand I would prefer to move it away from committing.rst, but on the
other
Chris Jerdonek added the comment:
I just talked to Ezio on IRC about this. I think it will be a lot easier to
review and see what's going on with these changes if they are put forth in
smaller, bite-sized pieces and committed incrementally. It's harder to
understand and have a dialogue
Ezio Melotti added the comment:
I added more comments on bitbucket to indicate the new parts, the ones that
have been moved, and the ones that have been removed. That should make reviews
easier.
I still haven't looked at the original FAQs (in faqs.rst), and still have to
decide what should
Chris Jerdonek added the comment:
I think it could cause confusion to have FAQs spread across two different files
because then we'll have to distinguish between two FAQs in our hyperlinks, and
it won't be obvious which FAQ page contains which questions.
I would recommend creating a new
Ezio Melotti added the comment:
I used FAQ-style titles to make easier to find the solution starting from a
problem (how do I do X?) and because I was planning to add more, but I can
revert them to normal titles.
So that would result in 4 sections:
* Active branches (was In what branches
Nick Coghlan added the comment:
The combination of the last two suggestions sounds good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
I made a separate repo to implement this and divided the previous commits in
smaller ones: https://bitbucket.org/ezio_melotti/devguide-14468
If this is OK, I'll start regrouping the FAQs in faqs.rst and then move there
the section about long-term development of
Ezio Melotti added the comment:
FTR I created a bitbucket clone of the devguide to make reviews easier:
Here you can find the rendered output:
https://bitbucket.org/ezio_melotti/devguide/src/default/committing.rst?at=default
Here you can find the patches I applied and comment on them:
Ezio Melotti added the comment:
Here is another iteration of the patch.
I removed some of the old material, added half of the FAQs and the title and
outline for the other FAQs. If the structure looks good I'll proceed.
--
assignee: sandro.tosi - ezio.melotti
Added file:
Changes by Ezio Melotti ezio.melo...@gmail.com:
Added file: http://bugs.python.org/file28629/committing.rst
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
I just noticed that the devguide already contains a section in the FAQ about
Mercurial. Would it make sense to move/keep questions for committers only in
the committing.rst page, and leave the generic question in faq.rst?
--
Chris Jerdonek added the comment:
Since this patch is on the longer side, would it be possible to use the Remote
hg repo feature so Rietveld will work? I assume this is possible for devguide
patches.
Regarding the FAQ, it seems preferable to me to keep all questions in the FAQ,
even if
Ezio Melotti added the comment:
Since this patch is on the longer side, would it be possible to use
the Remote hg repo feature so Rietveld will work?
I was actually thinking about doing this for the devguide and for the peps
repos, using the components to determine what repo should be used.
Chris Jerdonek added the comment:
I'm not sure the remote hg repo supports non-cpython repos.
Can you try? I would be surprised if it didn't.
What I was doing was converting the current prose in smaller FAQ-like sections
Okay, then it sounds like they're more like sections that fit into
Ezio Melotti added the comment:
Can you try? I would be surprised if it didn't.
IIRC it does a diff between the head of the cpython repo and the head of the
linked one.
Okay, then it sounds like they're more like sections that fit into
the natural flow of the main body of text.
Yes, the
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
hgrepos: +168
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
hgrepos: -168
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
hgrepos: +169
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list
Chris Jerdonek added the comment:
Sorry, my apologies for the mess-ups!
--
hgrepos: +170
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
hgrepos: -169
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list
Chris Jerdonek added the comment:
Okay, it looks like you can't do it. It failed with a repository is
unrelated error.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
The attached patch adds a couple of section about the single and multiple
clones approaches. The patch is still incomplete, because the rest of the page
should be adapted to the new content (in particular the old sections should be
removed, and the whole
Chris Jerdonek added the comment:
Content-wise the patch looks pretty good. I agree with the recommendations. A
couple suggestions though: I would break up the 20 lines of command-line
commands. Right now that chunk is a bit too long to grasp meaningfully. My
suggestion would be to break
Ezio Melotti added the comment:
I would break up the 20 lines of command-line commands.
I would have to find a compromise for this, because on one hand it's convenient
to have all the commands in a single place (so it's easy to get an overview),
but on the other hand that block includes
Chris Jerdonek added the comment:
One thing that occurred to me is that it is often or usually not sufficient to
go from 2.7 to 3.2 and on forward because applying a patch made against the
default branch loses information if first applied to an earlier branch. The
given workflow assumes no
Ezio Melotti added the comment:
It can probably be added to the list of FAQs, or mentioned together with null
merges.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
Ezio Melotti added the comment:
hg graft should also be mentioned. I now use hg graft 2.7 instead of hg
export 2.7 | hg import - to copy changeset from 2.7 to 3.2 (and then merge on
3.3/3.x).
--
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Note that hg graft is already mentioned/discussed in the devguide here:
http://docs.python.org/devguide/committing.html#porting-between-major-versions
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
FTR I now switched to hg share, and while I think it's a better option for
committers that work on several branches on a daily basis, it might not be the
same for contributors that usually prepare patches against default.
--
Changes by Mike Hoy mho...@gmail.com:
--
nosy: -mikehoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list mailing list
Changes by Mike Hoy mho...@gmail.com:
--
nosy: +mikehoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Python-bugs-list mailing list
Éric Araujo added the comment:
FWIW I agree with Antoine’s comments.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
___
___
Sandro Tosi added the comment:
Hi Ezio, thanks for the review: how about this new version of the patch? I've
left the more verbose version in the 3.2 example, while used the more compact
way for the 2.7 .
Re first committing to 2.7 then 3.2 and then merge, that would work for doc
patches,
Chris Jerdonek added the comment:
It might be worth mentioning and/or linking to some of the branching tips
discussed in the FAQ. For example, using `hg share` instead of `hg clone`
eliminates the need to pull between repositories/working directories:
Antoine Pitrou added the comment:
Sandro, I find your patch is really a regression:
-* Then clone it to create another local repository which is then used to
- checkout branch 3.2::
+* Then clone it to create another local repository for the 3.2 branch::
This makes the terminology ambiguous.
Sandro Tosi added the comment:
I think the aim of that part of the devguide is to give one clear, simple,
working way to operate on different branches at the same time. Additional
workflows can be presented, but probably in another place (like the FAQ
indeed). What others thing about this?
1 - 100 of 111 matches
Mail list logo
