On 3/6/2011 12:44 PM, Antoine Pitrou wrote:
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
At this point you can push to the public repo from your "3.2" clone, or
repeat the above push& merge to your "default" clone (with the
"default" branch checked out) and push from there
Martin> "Included", but not "available". The changes are in your "3.2
Martin> clone", but not in the "3.2 branch" of the "3.2 clone". Each
Martin> clone has all branches, even if you only "update" to one of
Martin> them.
Martin> So after "hg push", the change is on the "3.1 br
Beside Martin's answer, you might want to read:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
or perhaps:
http://hginit.com/
Regards
Antoine.
Le dimanche 06 mars 2011 à 14:46 -0600, s...@pobox.com a écrit :
> Antoine> Yes, there is. You can simply push to your 3.2 repo
Am 06.03.2011 21:46, schrieb s...@pobox.com:
Antoine> Yes, there is. You can simply push to your 3.2 repo instead:
Antoine> $ cd 3.1
Antoine> $ hg up 3.1# just in case
Antoine> # hack, compile, test
Antoine> $ hg ci -m "Issue #xxx: nasty bug now fixed"
An
Antoine> Yes, there is. You can simply push to your 3.2 repo instead:
Antoine> $ cd 3.1
Antoine> $ hg up 3.1# just in case
Antoine> # hack, compile, test
Antoine> $ hg ci -m "Issue #xxx: nasty bug now fixed"
Antoine> $ hg push ../3.2
Antoine> $ cd ../3.2
Antoi
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
> Assume I have separate 3.1 and 3.2 sandboxes
> which are sibling directories of each other, and that I commit a change to
> my 3.1 sandbox, how do I merge the change from 3.1 to 3.2? Assume I don't
> understand the instructions lat
On Sat, Mar 5, 2011 at 11:39, Georg Brandl wrote:
> Also please redirect praise to Antoine Pitrou and Dirkjan Ochtman who did
> most of the actual work.
>
> Georg
>
Many thanks to you three and anyone else who put in effort on this project.
It's excellent that this got completed in time for PyCo
Antoine> This is sketched out in the devguide, I don't know if these
Antoine> instructions help you:
Antoine> http://docs.python.org/devguide/committing.html#forward-porting
Thanks. There is one problem (for me, at least):
Assuming you are doing all of your work in a single clon
Le dimanche 06 mars 2011 à 09:50 -0600, s...@pobox.com a écrit :
> Antoine> "Martin v. Löwis" wrote:
> >> What is the recommended merge flow if I want to make this change to
> >> all branches?
>
> Antoine> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain
> Antoine>
Antoine> "Martin v. Löwis" wrote:
>> What is the recommended merge flow if I want to make this change to
>> all branches?
Antoine> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain
Antoine> 2.5)
Antoine> - on the other hand: 3.1 -> 3.2 -> default
Sorry,
On Sun, 06 Mar 2011 00:37:32 +0100
"Martin v. Löwis" wrote:
> What is the recommended merge flow if I want to make this change to
> all branches?
- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default
Regards
Antoine.
__
>Another possibility is to set Visual Studio project files to CRLF
> but this is less compatible with how svn has been used. The advantage
> to explicit CRLF is that if you clone onto a Unix system and then
> share that disk with Windows or create an archive that is expanded on
> Windows (in bi
On Sun, 6 Mar 2011 10:27:14 +1100
Neil Hodgson wrote:
>To minimize differences from previous behaviour, it is probably
> best to mimic svn more closely by changing .hgeol to either have all
> the project files as native or allow fall through to the default ** =
> native.
If it's only cosmetic
To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.
Another possibility is to set Visual Studio project files to CRLF
but this is les
Am 05.03.2011 23:33, schrieb Antoine Pitrou:
> Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit :
>> Antoine Pitrou:
>>
>>> It mimicks their settings in the SVN repository, so it should be ok.
>>
>>It doesn't match how they are checked out by svn since they have
>> the property svn:
Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit :
> Antoine Pitrou:
>
> > It mimicks their settings in the SVN repository, so it should be ok.
>
>It doesn't match how they are checked out by svn since they have
> the property svn:eol-style set to 'native'. Therefore these files a
Antoine Pitrou:
> It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
checked out by svn with Windows \r\n line ends.
Neil
___
On Sun, 6 Mar 2011 08:51:01 +1100
Neil Hodgson wrote:
> Georg Brandl:
>
> > I'm very happy to announce that the core Python repository switch
> > to Mercurial is complete and the new repository at
> > http://hg.python.org/cpython/ is now officially open for cloning,
>
>OK, I just performed a
Georg Brandl:
> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
OK, I just performed a clone OK. It seems wrong to me that the
*.vcproj and *.vsprops files
On Sat, Mar 5, 2011 at 12:39 PM, Georg Brandl wrote:
> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
> and for commits by those who had commit access to SVN.
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
and for commits by those who had commit access to SVN.
The developers' guide at http://docs.python.org/devguide/ ha
21 matches
Mail list logo
