Applying a patch to a clone
J. Cooley
using. I have not done this before and I want to make sure that I
apply it to the clone and not the main. I'm not entirely sure how to
do this.
Also, this patch seems to rely upon another from ticket #6672, so do I
need to add the three files from that ticket first in order and then
the two from ticket #6384?
Cheers.
John Cremona
[To the list: Jenny is an undergraduate working with me for a few
weeks on a project implementing some elliptic curve things in Sage.
Obviously I'm showing her how to use Sage, but I've been very busy
with other stuff lately so she is also getting help from others!]
John
2009/8/26 J. Cooley <j.a.c...@warwick.ac.uk>:
Carlo Hamalainen
First make a clone:
sage -clone mybranch
Switch to the clone:
sage -b mybranch
Download the patches from trac, say blah1.patch, blah2.patch, and apply them:
cd $SAGE_ROOT/sage/devel/sage
hg qinit
If the qinit command fails then you may need to edit your .hgrc file;
see http://wiki.sagemath.org/MercurialQueues
Now apply the two patches:
hg qimport /somewhere/blah1.patch
hg qpush
hg qimport /somewhere/blah2.patch
hg qpush
Rebuild sage:
sage -b
--
Carlo Hamalainen
http://carlo-hamalainen.net
David Joyner
1. cd to the SAGE_ROOT directory
2. ./sage -b main (this assures you are starting from the main
branch and not cloning form a clone)
3. ./sage -clone ABCDx (where ABCD is the trac number you are
applying the patch from and x=a for the first clone,
x=b for the second clone, if needed, and so on)
4. ./sage (start sage)
5. type hg_sage.apply("/path/to/the/patch/trac_ABCD_blahblah.patch")
6. ctl-D (quit sage)
7. ./sage -b (to rebuild) or ./sage -br (to rebuild and restart sage).
kcrisman
On Aug 26, 11:06 am, David Joyner <wdjoy...@gmail.com> wrote:
> The way I do this (which may not be the best way) is
>
> 1. cd to the SAGE_ROOT directory
> 2. ./sage -b main (this assures you are starting from the main
> branch and not cloning form a clone)
> 3. ./sage -clone ABCDx (where ABCD is the trac number you are
> applying the patch from and x=a for the first clone,
> x=b for the second clone, if needed, and so on)
> 4. ./sage (start sage)
> 5. type hg_sage.apply("/path/to/the/patch/trac_ABCD_blahblah.patch")
hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
it is MUCH easier to remove the patch after you test it. That means
no more needing to make a new clone for each test, and allows people
like me to avoid using queues just a little bit longer.
- kcrisman
> 7. ./sage -b (to rebuild) or ./sage -br (to rebuild and restart sage).
>
John Cremona
>
> It is worth pointing out that if one uses
>
> hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
>
> it is MUCH easier to remove the patch after you test it. That means
> no more needing to make a new clone for each test, and allows people
> like me to avoid using queues just a little bit longer.
>
Interesting -- can you supply more details (and or a reference)?
I have used hg_sage.apply() many times; how does import_patch() differ?
John
Nils Bruin
> Interesting -- can you supply more details (and or a reference)?
>
> I have used hg_sage.apply() many times; how does import_patch() differ?
>
sage: hg_sage.apply?
Type: instancemethod
Base Class: <type 'instancemethod'>
String Form: <bound method HG.unbundle of Hg repository 'Sage
Library Source Code' in directory /usr/local/sage/4.1.1/devel/sage>
Namespace: Interactive
File: /usr/local/sage/4.1.1/local/lib/python2.6/site-
packages/sage/misc/hg.py
Definition: hg_sage.apply(self, bundle, update=True, options='')
Docstring:
Apply patches from a hg patch to the repository.
If the bundle is a .patch file, instead call the
import_patch
method. To see what is in a bundle before applying it,
using
self.incoming(bundle).
INPUT:
- ``bundle`` - an hg bundle (created with the bundle
command)
- ``update`` - if True (the default), update the
working directory after unbundling.
William Stein
>
>
>
> On Aug 26, 11:06 am, David Joyner <wdjoy...@gmail.com> wrote:
>> The way I do this (which may not be the best way) is
>>
>> 1. cd to the SAGE_ROOT directory
>> 2. ./sage -b main (this assures you are starting from the main
>> branch and not cloning form a clone)
>> 3. ./sage -clone ABCDx (where ABCD is the trac number you are
>> applying the patch from and x=a for the first clone,
>> x=b for the second clone, if needed, and so on)
>> 4. ./sage (start sage)
>> 5. type hg_sage.apply("/path/to/the/patch/trac_ABCD_blahblah.patch")
>
> It is worth pointing out that if one uses
>
> hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
>
> it is MUCH easier to remove the patch after you test it. That means
> no more needing to make a new clone for each test, and allows people
> like me to avoid using queues just a little bit longer.
You don't have to do that. You can do:
sage: hg_sage.apply('... url ...')
sage: quit
./sage -br
sage: <try it out>
This needs work! Argh.
sage: hg_sage.rollback()
sage: hg_sage.revert('--all')
sage: quit
Now your repo is as if you never applied the patch.
You can only rollback one time though, so you can't apply multiple
patches -- if you want to to that you need to clone or use queues.
William
John Cremona
question I knew that the answer was "check the documentation" and did
so....
It never ceases to amaze me how many slightly different ways there are
of doing things, and that we all use slightly different variants!
One reason why I have (temporarily, I expect) stopped using hg queues
was that it was pointed out to me that the patches I made from there
(hg export qtip) did not have a proper commit message. I read all the
documentation, did what it said -- but still there was no commit
message in the patch. I'm sure someone will now tell me what is the
right way to do that (but please don't just point me to the
documentation this time, as what I fould there sis not work for me!)
John
Alex Ghitza
> One reason why I have (temporarily, I expect) stopped using hg queues
> was that it was pointed out to me that the patches I made from there
> (hg export qtip) did not have a proper commit message. I read all the
> documentation, did what it said -- but still there was no commit
> message in the patch.
Hi John,
Here is what I do, although it's probably not the right way to do
things: after hg export qtip, I load the resulting patch file in emacs
and insert the commit message by hand. More precisely, I replace the
first line after the hg "comments", which just says [mq] something,
with a reasonable commit message. If I have time and am not sleep
deprived (so, basically never) this also gives me a chance to have a
last look over the patch and see if I forgot anything -- my emacs
displays diff files in a nice readable way, so it's fairly pleasant.
Again, I'm not claiming this is "the right way" to do it, but it works
for me and it's fairly quick.
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Minh Nguyen
On Thu, Aug 27, 2009 at 6:30 PM, John Cremona<john.c...@gmail.com> wrote:
<SNIP>
> One reason why I have (temporarily, I expect) stopped using hg queues
> was that it was pointed out to me that the patches I made from there
> (hg export qtip) did not have a proper commit message.
The person who pointed that out to you is me :-)
> I read all the
> documentation, did what it said -- but still there was no commit
> message in the patch. I'm sure someone will now tell me what is the
> right way to do that (but please don't just point me to the
> documentation this time, as what I fould there sis not work for me!)
In addition to Alex's suggestion, here's another tip to ensure you
have a proper, sensible commit message. After making the necessary
changes, you can refresh your patch with
hg qrefresh -e
where the optional argument "-e" tells Mercurial to open an editor for
you to write your commit message. After you have entered your commit
message in the editor, quit the editor and the commit message is saved
with the refreshed patch.
--
Regards
Minh Van Nguyen
Carlo Hamalainen
>
> On Thu, Aug 27, 2009 at 6:30 PM, John Cremona<john.c...@gmail.com> wrote:
>> One reason why I have (temporarily, I expect) stopped using hg queues
>> was that it was pointed out to me that the patches I made from there
>> (hg export qtip) did not have a proper commit message. I read all the
>> documentation, did what it said -- but still there was no commit
>> message in the patch.
>
> Hi John,
>
> Here is what I do, although it's probably not the right way to do
> things: after hg export qtip, I load the resulting patch file in emacs
> and insert the commit message by hand. More precisely, I replace the
> first line after the hg "comments", which just says [mq] something,
> with a reasonable commit message. If I have time and am not sleep
> deprived (so, basically never) this also gives me a chance to have a
> last look over the patch and see if I forgot anything -- my emacs
> displays diff files in a nice readable way, so it's fairly pleasant.
Are you doing hg qnew -e ?
# The -e pops up an editor for me to enter a commit message
# The -f retroactively saves my changes as a patch
# (the changes visible in hg diff)
hg qnew -e -f mypatch.patch
More info here: http://wiki.sagemath.org/MercurialQueues
John Cremona
editing patches by hand, surely that should be a last resort!
To Minh: I think this is what I was looking for (hg qrefresh -e). I
had tried hg qrefresh -m "commit message" but it did not work. I will
try this next time.
To Carlo: thanks for updating the wiki on queues, which has grown
since I last looked. I find your solution rather counterintuitive
though: surely ones does "hg -qnew" at the beginning of some work, so
that seems a funny time to write the commit message? But I don't
understand what you mean by the comment "The -f retroactively saves my
changes as a patch" either. Surely you are not editing files *before*
the qnew?
John
PS admire my netiquette: no automatic quotes!
Carlo Hamalainen
> To Carlo: thanks for updating the wiki on queues, which has grown
> since I last looked. I find your solution rather counterintuitive
> though: surely ones does "hg -qnew" at the beginning of some work, so
> that seems a funny time to write the commit message? But I don't
> understand what you mean by the comment "The -f retroactively saves my
> changes as a patch" either. Surely you are not editing files *before*
> the qnew?
Actually I didn't edit that wiki page, and I do find it a bit
mysterious to be entering the commit message at that point in the
process. Can any Mercurial guru enlighten us?
John Cremona
That text was entered by Jason (according to the wiki revision history).
John
Alex Ghitza
>>> since I last looked. I find your solution rather counterintuitive
>>> though: surely ones does "hg -qnew" at the beginning of some work, so
>>> that seems a funny time to write the commit message? But I don't
>>> understand what you mean by the comment "The -f retroactively saves my
>>> changes as a patch" either. Surely you are not editing files *before*
>>> the qnew?
I have to use hg qnew -f fairly often in the following situation: I am
looking at a trac ticket, find the source file in the Sage library
where things need to be fixed/added, and start playing with it.
Eventually I give up or find a solution, at which point I realise that
I forgot to create a new patch in the queue. So I resort to -f and
the universe is ok again. :)
Pat LeSmithe
> To Carlo: thanks for updating the wiki on queues, which has grown
> since I last looked. I find your solution rather counterintuitive
> though: surely ones does "hg -qnew" at the beginning of some work, so
> that seems a funny time to write the commit message? But I don't
> understand what you mean by the comment "The -f retroactively saves my
> changes as a patch" either. Surely you are not editing files *before*
> the qnew?
Sometimes, yes. I usually use
hg qnew -e -f trac_XXXX-do_something.patch
after I realize that my most recent changes should comprise a new patch.
For example, the changes may be more than a simple revision to the
topmost applied patch, on a different topic, highly experimental, etc.
I substitute the appropriate ticket number, if I happen to have it. The
first commit message just summarizes what I've done so far and perhaps
also what's left to do.
John Cremona
(1) adding -e to the qnew command pops up an editor for you to enter a
commit message; so does adding -e to a qrefresh command, so you can
update that message later.
(2) normally qnew will abort if it finds any modifications. But qnew
-f will not only allow that (-f means "force", I think), it knows
exactly what edits you have done and effectively backdates the qnew
operation to the points before you made those edits, so that the
current state is the same as if you had done the qnew before making
those edits.
That last feature is one I have often missed -- as Alex says, it's a
common situation, to forget to do qnew after importing and pushing a
patch and then making edits. There are many times in the past when
knowing this would have saved me a lot of work.
Somehow, reading both the mercurial queues manual and the sage wiki
version of the same, there were still things not understood (by me)!
John
2009/8/27 Pat LeSmithe <qed...@gmail.com>:
kcrisman
>
> > hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
>
> > it is MUCH easier to remove the patch after you test it. That means
> > no more needing to make a new clone for each test, and allows people
> > like me to avoid using queues just a little bit longer.
>
> You don't have to do that. You can do:
>
> sage: hg_sage.apply('... url ...')
> sage: quit
>
> ./sage -br
>
> sage: <try it out>
> This needs work! Argh.
> sage: hg_sage.rollback()
> sage: hg_sage.revert('--all')
> sage: quit
>
> Now your repo is as if you never applied the patch.
>
> You can only rollback one time though, so you can't apply multiple
> patches -- if you want to to that you need to clone or use queues.
>
rollback. That not only saves a step, it means I could theoretically
apply several patches without a commit, and then revert them all at
once. Right? I haven't actually tried doing that... but as I said,
it's all because I need a personal queues tutorial session before I
use them.
- kcrisman
Jason Grout
>>>> To Carlo: thanks for updating the wiki on queues, which has grown
>>>> since I last looked. I find your solution rather counterintuitive
>>>> though: surely ones does "hg -qnew" at the beginning of some work, so
>>>> that seems a funny time to write the commit message? But I don't
>>>> understand what you mean by the comment "The -f retroactively saves my
>>>> changes as a patch" either. Surely you are not editing files *before*
>>>> the qnew?
>
> I have to use hg qnew -f fairly often in the following situation: I am
> looking at a trac ticket, find the source file in the Sage library
> where things need to be fixed/added, and start playing with it.
> Eventually I give up or find a solution, at which point I realise that
> I forgot to create a new patch in the queue. So I resort to -f and
> the universe is ok again. :)
>
That describes my usual procedure, which is why the wiki says "hg qnew -f"
If you are disciplined enough to realize that you are going to fix
something in the next N minutes, then by all means, go ahead and do hg
qnew before starting your project. I think I've remembered to do that
about 3 times in the last 1.5 years.
Jason
Jason Grout
> Somehow, reading both the mercurial queues manual and the sage wiki
> version of the same, there were still things not understood (by me)!
Of course, the obvious request now is to ask you to update the sage wiki
so that you would have understood it :).
Jason
Stan Schymanski
I tried different ways of applying a patch and probably made a bit of a
mess in my repository. Is there a way to revert it back to a clean 4.1.1
install? I keep getting a message about an uncommitted merge...
Here is what I did in OSX 10.4:
----------------------------------------------------------------------
| Sage Version 4.1.1, Release Date: 2009-08-14 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: hg_sage.revert('--all')
WARNING:
Make sure to create a ~/.hgrc file:
----------------------------------------------------------------------
[ui]
username = William Stein <wst...@gmail.com>
----------------------------------------------------------------------
cd "/Users/sschym/Programs/sage/devel/sage" && hg revert --all
abort: uncommitted merge - please provide a specific revision
Thanks for your help!
Stan