I am now lost - committed, pulled, merged, what is "collapse"?

classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

I am now lost - committed, pulled, merged, what is "collapse"?

Skip Montanaro-3

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://[hidden email]/cpython
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 94 changesets with 422 changes to 154 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
    cpython% hg merge
    132 files updated, 0 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)

hg heads showed my changeset:

    changeset:   68585:c63d7374b89a
    user:        Skip Montanaro <[hidden email]>
    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 <[hidden email]>
    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)?  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?

Skip
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

"Martin v. Löwis"
> hg heads showed my changeset:
>
>     changeset:   68585:c63d7374b89a
>     user:        Skip Montanaro <[hidden email]>
>     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 <[hidden email]>
>     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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

R. David Murray
In reply to this post by Skip Montanaro-3
On Sat, 19 Mar 2011 09:25:07 -0500, [hidden email] 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Antoine Pitrou
In reply to this post by Skip Montanaro-3
On Sat, 19 Mar 2011 09:25:07 -0500
[hidden email] 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://[hidden email]/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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Skip Montanaro-3
In reply to this post by R. David Murray

    >> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Raymond Hettinger-4
In reply to this post by Antoine Pitrou

On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:

> On Sat, 19 Mar 2011 09:25:07 -0500
> [hidden email] 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Skip Montanaro-3
In reply to this post by Antoine Pitrou
>>>>> "Antoine" == Antoine Pitrou <[hidden email]> writes:

    Antoine> On Sat, 19 Mar 2011 09:25:07 -0500
    Antoine> [hidden email] 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://[hidden email]/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 - [hidden email] - http://www.smontanaro.net/
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

"Martin v. Löwis"
In reply to this post by Raymond Hettinger-4
> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Nick Coghlan
In reply to this post by Skip Montanaro-3
On Sun, Mar 20, 2011 at 5:05 AM,  <[hidden email]> 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   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Guido van Rossum
In reply to this post by "Martin v. Löwis"
On Sat, Mar 19, 2011 at 12:55 PM, "Martin v. Löwis" <[hidden email]> 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://[hidden email]/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 [hidden email] of incoming changeset 3074c77b7121
remote: notified [hidden email] of incoming changeset cf5e4bdb24a1
remote: notified [hidden email] of incoming changeset 89007356798b
remote: notified [hidden email] of incoming changeset cc959f114739
remote: notified [hidden email] of incoming changeset 69650b81f4b9
remote: notified [hidden email] 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Antoine Pitrou
On Sat, 19 Mar 2011 16:32:53 -0700
Guido van Rossum <[hidden email]> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Nick Coghlan
In reply to this post by Guido van Rossum
On Sun, Mar 20, 2011 at 9:32 AM, Guido van Rossum <[hidden email]> 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   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

zipher
In reply to this post by Raymond Hettinger-4
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger
<[hidden email]> wrote:

> On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
>> On Sat, 19 Mar 2011 09:25:07 -0500
>> [hidden email] 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Paul Boddie
In reply to this post by Skip Montanaro-3
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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

"Martin v. Löwis"
In reply to this post by Guido van Rossum
> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

"Martin v. Löwis"
In reply to this post by Antoine Pitrou
Am 20.03.2011 00:39, schrieb Antoine Pitrou:

> On Sat, 19 Mar 2011 16:32:53 -0700
> Guido van Rossum <[hidden email]> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Ned Deily
In reply to this post by Nick Coghlan
In article
<[hidden email]>,
 Nick Coghlan <[hidden email]> 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,
 [hidden email]

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Avoiding whitespace conflicts (was: I am now lost - committed, pulled, merged, what is "collapse"?)

Ben Finney-10
Ned Deily <[hidden email]> writes:

> 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.

Even earlier that the attempt to commit, one can configure the text
editor to show whitespace in order to be aware of it at the point where
it's easiest to change:

    Emacs:

        M-x whitespace-mode RET

    Vim:

        :set list listchars=trail:·,tab:»·

Or, instead of all whitespace, highlight trailing whitespace as an
error:

    Emacs:

        M-: (setq show-trailing-whitespace t) RET

    Vim:

        :set list listchars=trail:·,tab:»·
        :highlight SpecialKey ctermfg=Yellow ctermbg=Red

Of course, any Python programmer hoping to comply with PEP 8 is best
advised to never insert a U+0009 HORIZONTAL TAB character:

    Emacs:

        M-: (setq indent-tabs-mode nil) RET

    Vim:

        :set expandtabs

One can even tell the editor to remove all the trailing whitespace:

    Emacs:

        M-x delete-trailing-whitespace RET

    Vim:

        :%s:\s\+$::

More:

    <URL:http://www.emacswiki.org/emacs/WhiteSpace>
    <URL:http://stackoverflow.com/questions/3165503/emacs-global-configuration-of-tabs>

    <URL:http://vim.wikia.com/wiki/Highlight_unwanted_spaces>
    <URL:http://vim.wikia.com/wiki/Remove_unwanted_spaces>
    <URL:http://stackoverflow.com/questions/69998/tabs-and-spaces-in-vim>

This allows a belt-and-braces approach: the repository will reject
attempts to commit with whitespace mistakes, but one's text editor can
be an ally in never getting to that point.

--
 \       “For fast acting relief, try slowing down.” —Jane Wagner, via |
  `\                                                       Lily Tomlin |
_o__)                                                                  |
Ben Finney

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

R. David Murray
In reply to this post by Skip Montanaro-3
On Sat, 19 Mar 2011 13:53:11 -0500, [hidden email] 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: I am now lost - committed, pulled, merged, what is "collapse"?

Jesus Cea-2
In reply to this post by Raymond Hettinger-4
-----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                         _/_/      _/_/_/        _/_/_/
[hidden email] - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:[hidden email]         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
12345