Sage Developer's Guide - Mirrors

More documents

Recommendations

Info

Sage Developer’s Guide, Release 6.1.1encouraged to split your work into logically different parts. Ideally, each part that is useful on its own and and can bereviewed independently should be a different ticket, instead of a huge patch bomb.For this purpose, you can incorporate branches from other tickets (or just other local branches) into your currentbranch. This is called merging, and all it does is include commits from other branches into your current branch. Inparticular, this is done when a new Sage release is made: the finished tickets are merged with the Sage master and theresult is the next Sage version. Git is smart enough to not merge commits twice. In particular, it is possible to mergetwo branches, one of which had already merged the other branch.The syntax for merging is easy. If the code that you want to incorporate is on a trac ticket number ,use:[user@localhost]$ sage -dev merge --ticket Optionally, you can add the merged ticket to the trac “Dependency:” field. Note that the merged commits become partof the current branch, regardless of whether they are noted on trac. Adding a dependency implies that the dependencymust be reviewed first. After the dependency is reviewed, the commits that came from the dependency are no longerlisted in the output of sage -dev diff.Warning: You should avoid merging tickets both ways. Once ticket A merged ticket B and ticket B merged ticketA, there is no way to distinguish commits that were originally made in ticket A or in ticket B. Effectively, mergingboth ways combines the branches and makes individual review impossible.In practice, you should only merge when one of the following holds:• Either two tickets conflict, then you have to merge one into the other in order to resolve the merge conflict.• Or you definitely need a feature that has been developed as part of another branch.A special case of merging is merging in the master branch. This brings your local branch up to date with the newestSage version. The above warning against unnecessary merges still applies, though. Try to do all of your developmentwith the Sage version that you originally started with. The only reason for merging in the master branch is if you needa new feature or if your branch conflicts.1.3 ReviewingNow suppose you want to review the existing work on a ticket, such as the one you created in the last section. Fordefiniteness, suppose you want to review #12270. You would do that as follows:[user@localhost]$ sage -dev checkout --ticket 12270This command will download the branch on Trac in case you do not have any local work on ticket 12270. (If you do,you may have to merge your changes; see below). You can now test the ticket; you’ll probably want to call make orsage -b first to rebuild Sage with the changes. Another important command is:[user@localhost]$ sage -dev diffwhich lists all source code changes that are part of the current branch. That is, it lists the changes from the currentmaster to the current branch. If the ticket were to be positively reviewed, this is the code that will be added to Sage.Note that there is no way to “exclude dependencies”, just as there is no guarantee that unreviewed dependencieswill become part of Sage. The best way to exclude dependencies from the diff output is to review them. Once thedependency becomes part of the master branch, they are automatically removed.Most likely, your will want to add a comment to the ticket as part of your review:[user@localhost]$ sage -dev commentThis will open a text editor in which you can type, and upload the result to Trac.6 Chapter 1. Sage Development Process
Sage Developer’s Guide, Release 6.1.1It is also possible that you make some changes to the code as part of your review. After you have done that, you canupload your changes back to trac:[user@localhost]$ sage -dev commit[user@localhost]$ sage -dev pushThis will update the ticket to now point to your branch, including your changes. Your branch is based on the originalauthor’s branch, so s/he can easily incorporate your changes into his/her own branch (see below).1.4 CollaborationIt is very easy to collaborate by just going through the above steps any number of times:# developer 1sage -dev commitsage -dev push# developer 2sage -dev pullsage -dev commitsage -dev push# developer 1sage -dev pullsage -dev commitsage -dev push(etc)The obvious problem is when you both work on the same ticket simultaneously:# developer 1sage -dev commitsage -dev push# developer 2sage -dev commitsage -dev pushChanges not compatible with remote branchu//ticket/12270; considerdownloading first. Are you sure you want to continue?Developer 2 should probably select No, and do as suggested:sage -dev pullThis will try to merge the changes developer 1 made into the ones that developer 2 made. The latter should checkwhether all seems okay, and if so, upload the changes:sage -dev push# works nowIt is possible that the changes cannot be automatically merged. In that case, developer 2 will have to do some manualfixup after downloading and before uploading:1.4. Collaboration 7
Page 1: Sage Developer’s GuideRelease 6.1
Page 4 and 5: 7 Indices and tables 129Bibliograph
Page 6 and 7: Sage Developer’s Guide, Release 6
Page 60 and 61:
Sage Developer’s Guide, Release 6
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
show all

Sage Developer's Guide - Mirrors

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?