creating a local patch

[Luis Finotti]

Dear all,

I had some changes made in a older version of sage.  I wanted to create a patch that I can apply to a new install, without uploading to trac (as the changes are not "good enough").  Can anyone tell me the necessary commands or point me in the right direction?

Best,

Luis

[Michael Orlitzky]

In general, if you're trying to sidestep the mercurial workflow, all you
have to do is get an original copy of the file and run,

diff -u <original> <modified> > foo.patch

to save the differences in a patch named "foo.patch".

Depending on the file you modified, getting the original may be as
simple as downloading the old version of sage again.

[Jason Grout]

I would do something like:

cd OLD_SAGE/devel/sage/
../../sage -hg diff # check to see if these are the changes you want
../../sage -hg qnew mychanges.patch
../../sage -hg export qtip > /SOME/DIR/mychanges.patch

Then go to your new Sage install, and do

cd NEW_SAGE/devel/sage/
../../sage -hg qimport /SOME/DIR/mychanges.patch
../../sage -hg qpush

There might be conflicts at that point. It'll tell you which hunks
failed to apply and where the rejection files are.

Thanks,

Jason

[Simon King]

Hi Luis,

On 2012-08-30, Michael Orlitzky <mic...@orlitzky.com> wrote:
> On 08/30/2012 12:36 PM, Luis Finotti wrote:
>> Dear all,
>>
>> I had some changes made in a older version of sage. I wanted to create
>> a patch that I can apply to a new install, without uploading to trac (as
>> the changes are not "good enough"). Can anyone tell me the necessary
>> commands or point me in the right direction?
>

> In general, if you're trying to sidestep the mercurial workflow, ...

Are you? It seems to me that following the mercurial workflow is the
thing to do here.

If I understand correctly, you want to do a change in an old Sage
version and then apply the same change to a new version, but you do not
want to post the change to trac. So, why not simply create a patch with
mercurial in the old version (perhaps using mercurial queues) and apply
it to the new version? Of course, you *could* post such patch on trac -
but nobody forces you to actually do so.

Hence:
* both in the old and in the new version, go to $SAGE_ROOT/devel/sage,
and do "hg qinit" (if not done already).
* Start a new patch in your old Sage version: "hg qnew my.patch"
* Do the changes in your old Sage version. Create the patch:
"hg qrefresh"
You can repeat changing and refreshing as long as you like.
* When the changes are done: "hg export qtip > /path/to/my.patch"
* Now change to your new Sage version (in $SAGE_ROOT/devel/sage).
Do "hg qimport /path/to/my.patch"
* The previous command was importing the patch, but not *applying* it.
Hence, do "hg qpush"
* Rebuild your new Sage version ("../../sage -br" or so)

Best regards,
Simon

[Nils Bruin]

On Aug 30, 9:54 am, Simon King <simon.k...@uni-jena.de> wrote:
>    Do "hg qimport /path/to/my.patch"
>  * The previous command was importing the patch, but not *applying* it.
>    Hence, do "hg qpush"
>  * Rebuild your new Sage version ("../../sage -br" or so)

I found the abbreviation

hg qimport -P ...

to combine the push with the import quite convenient, in particular
because repeated qimports without qpush would normally insert the more
recent imports *before* the older ones in the queue (which tripped me
up a couple of times).

[Luis Finotti]

Firstly, thanks all for the replies.

On Thursday, August 30, 2012 12:54:31 PM UTC-4, Simon King wrote:

Hi Luis,

On 2012-08-30, Michael Orlitzky <mic...@orlitzky.com> wrote:
>
> In general, if you're trying to sidestep the mercurial workflow, ...

Are you? It seems to me that following the mercurial workflow is the
thing to do here.

If I understand correctly, you want to do a change in an old Sage
version and then apply the same change to a new version, but you do not
want to post the change to trac. So, why not simply create a patch with
mercurial in the old version (perhaps using mercurial queues) and apply
it to the new version? Of course, you *could* post such patch on trac -
but nobody forces you to actually do so.

Posting a patch on trac would be the easiest thing for me (or at least I have instructions on how to do it) and I don't mind doing it at all.  My concern is that the code, at this point, is not usable and does not follow the recommendations for developers.  I'd very much like to use trac as my main version control repository, but it seems that I'd be polluting it with sub par code until close to the very end (which I am not sure how far ahead it will be).  If that is OK, let me know and I will just do that...

Best,

Luis

[Jason Grout]

On 8/30/12 12:42 PM, Luis Finotti wrote:
> Firstly, thanks all for the replies.
>
> On Thursday, August 30, 2012 12:54:31 PM UTC-4, Simon King wrote:
>
> Hi Luis,
>

> On 2012-08-30, Michael Orlitzky <mic...@orlitzky.com <javascript:>>

> wrote:
> >
> > In general, if you're trying to sidestep the mercurial workflow,

> ....

>
> Are you? It seems to me that following the mercurial workflow is the
> thing to do here.
>
> If I understand correctly, you want to do a change in an old Sage
> version and then apply the same change to a new version, but you do not
> want to post the change to trac. So, why not simply create a patch with
> mercurial in the old version (perhaps using mercurial queues) and apply
> it to the new version? Of course, you *could* post such patch on trac -
> but nobody forces you to actually do so.
>
>
> Posting a patch on trac would be the easiest thing for me (or at least I
> have instructions on how to do it) and I don't mind doing it at all. My
> concern is that the code, at this point, is not usable and does not
> follow the recommendations for developers. I'd very much like to use
> trac as my main version control repository, but it seems that I'd be
> polluting it with sub par code until close to the very end (which I am
> not sure how far ahead it will be). If that is OK, let me know and I
> will just do that...

I post in-progress code to trac because:

1. It's a backup of the code. There has been several times when I
wanted to go back to an old patch and work on it more, but the only
place I could find it was a copy I had put up on trac.
2. It lets others know I'm working on it, so they can contact me if they
want to help, or if they're interested in testing, etc.
3. All too often, I don't have time to finish it. Sometimes others come
and finish the patch for me! (Thanks everyone!)

I just clearly label the code as in-progress and list the current state
and issues with the code. (At least, I try to do that).

If/when we move to github or to bitbucket or something, where people can
easily push their own branches, it will be much more natural to push
your in-progress code up and collaborate.

Thanks,

Jason

[Jeroen Demeyer]

On 2012-08-30 19:51, Jason Grout wrote:
> I post in-progress code to trac because:
>
> 1. It's a backup of the code. There has been several times when I
> wanted to go back to an old patch and work on it more, but the only
> place I could find it was a copy I had put up on trac.
> 2. It lets others know I'm working on it, so they can contact me if they
> want to help, or if they're interested in testing, etc.
> 3. All too often, I don't have time to finish it. Sometimes others come
> and finish the patch for me! (Thanks everyone!)

+1

[Julien Puydt]

Le 30/08/2012 19:51, Jason Grout a �crit :

> If/when we move to github or to bitbucket or something, where people can
> easily push their own branches, it will be much more natural to push
> your in-progress code up and collaborate.

*IF* !?

Snark on #sagemath

[Jason Grout]

Progress seems to have stalled, and at least considering github, there
was at least one person who was strongly advocating for us to stay with
mercurial (IIRC, even offering to write code for Mercurial to fill in
feature holes we were missing, as well as educating us about some of the
really cool things going on in mecurial development these days).

I'd love to see this all move forward again.

Thanks,

Jason

[Luis Finotti]

On Thursday, August 30, 2012 1:52:17 PM UTC-4, jason wrote:

I post in-progress code to trac because:

1. It's a backup of the code.  There has been several times when I
wanted to go back to an old patch and work on it more, but the only
place I could find it was a copy I had put up on trac.
2. It lets others know I'm working on it, so they can contact me if they
want to help, or if they're interested in testing, etc.
3. All too often, I don't have time to finish it.  Sometimes others come
and finish the patch for me!  (Thanks everyone!)

I just clearly label the code as in-progress and list the current state
and issues with the code.  (At least, I try to do that).

If/when we move to github or to bitbucket or something, where people can
easily push their own branches, it will be much more natural to push
your in-progress code up and collaborate.

Thanks,

Jason

OK, I will go ahead and upload to trac.  On the other hand, a more careful read of the documentation (at http://www.sagemath.org/doc/developer/walk_through.html) showed me how to do what I initially wanted (or so I think): create a patch from the older version with hg_sage.commit() and hg_sage.export() and applying to the new version with hg_sage.apply.

Thanks all for the help,

Luis
 

[Keshav Kini]

Jason Grout <jason...@creativetrax.com> writes:
> On 8/30/12 1:10 PM, Julien Puydt wrote:

>> Le 30/08/2012 19:51, Jason Grout a écrit :
>>> If/when we move to github or to bitbucket or something, where people can
>>> easily push their own branches, it will be much more natural to push
>>> your in-progress code up and collaborate.
>>
>> *IF* !?
>
> Progress seems to have stalled, and at least considering github, there

We're not going to use github as a development platform, since we tried
it out in March and William didn't like it. We will be switching to git
(eventually), but development will continue to be on trac. There might
be a mirror of the repo on github.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[Jason Grout]

On 8/30/12 1:20 PM, Keshav Kini wrote:
> Jason Grout <jason...@creativetrax.com> writes:
>> On 8/30/12 1:10 PM, Julien Puydt wrote:

>>> Le 30/08/2012 19:51, Jason Grout a �crit :

>>>> If/when we move to github or to bitbucket or something, where people can
>>>> easily push their own branches, it will be much more natural to push
>>>> your in-progress code up and collaborate.
>>>
>>> *IF* !?
>>
>> Progress seems to have stalled, and at least considering github, there
>
> We're not going to use github as a development platform, since we tried
> it out in March and William didn't like it. We will be switching to git
> (eventually), but development will continue to be on trac. There might
> be a mirror of the repo on github.
>

There are definitely a lot of +1 and -1 things about github. They have
been improving quite a bit over the summer, but there are still some
nice things I like about trac and how you can organize things that are
still negatives about github.

However, having code and branch development on github and tracking the
bugs on trac are definitely not mutually exclusive. It would be good to
have a conversation about this sometime. I'm sure you guys have already
had lots of conversations.

What in particular was bothersome about github?

Thanks,

Jason

[David Roe]

>
> What in particular was bothersome about github?

I don't remember all the details, but I think having to deal with both
trac and github got very tiresome. We don't want to move completely
to github since we have a bunch of existing tickets and progress on
trac. So we decided to try making git work with trac, which seemed
like it should be possible.
David

[Robert Bradshaw]

Issue-tracking in particular is sub-par on github (though I've heard
they've been working on this), and having to both is a pain. There's
also the question of logging/preserving the development history.

Ideally, you should be able to use whatever tool you want and it would
all get aggregated to a central location (e.g. I'd like to be able to
make line-by-line comments on github, which could then get
automatically posted to the ticket).

- Robert

[Julien Puydt]

Le 31/08/2012 00:19, Robert Bradshaw a �crit :

> On Thu, Aug 30, 2012 at 12:17 PM, David Roe<roed...@gmail.com> wrote:
>>> What in particular was bothersome about github?

> Issue-tracking in particular is sub-par on github (though I've heard
> they've been working on this), and having to both is a pain. There's
> also the question of logging/preserving the development history.

For a one-tree mercurial project, preserving the development history is
trivial (ask "mercurial to git conversion" to any web search engine).
For something like sage where each spkg is it's own project tree, that
is much much less so.

This link can be of interest to the discussion:
http://stackoverflow.com/questions/623130/git-and-trac-or-similar

Snark on #sagemath

PS: Notice that Jason Grout's original sentence starting this subthread
was "If/when we move to github or to bitbucket or something, where

people can easily push their own branches, it will be much more natural

to push your in-progress code up and collaborate." -- and I choked on
the "If" because I think it's pretty clear the current organisation
doesn't work correctly -- collaboration is definitely too hard. It
wasn't about moving to github, it was about moving away from what is
used now.

[Keshav Kini]

Julien Puydt <julien...@laposte.net> writes:

> Le 31/08/2012 00:19, Robert Bradshaw a écrit :
>> On Thu, Aug 30, 2012 at 12:17 PM, David Roe<roed...@gmail.com> wrote:
>>>> What in particular was bothersome about github?
>
>> Issue-tracking in particular is sub-par on github (though I've heard
>> they've been working on this), and having to both is a pain. There's
>> also the question of logging/preserving the development history.
>
> For a one-tree mercurial project, preserving the development history
> is trivial (ask "mercurial to git conversion" to any web search
> engine). For something like sage where each spkg is it's own project
> tree, that is much much less so.

See http://github.com/kini/sage-workflow for some work on this. I wrote
a bash script which converts all of Sage's 90+ Mercurial repos into a
single git repository with a new directory structure.

[Michele]

Very, very interesting!

Michele