1,057
edits
Changes
From Gramps
no edit summary
==Log messages==
Every commit to Subversion Git must be accompanied by a log message. These messages will be generated into a ChangeLog when a release is made and should conform to the following guidelines:
* The first line of the commit message should consist of a short summary of the change.
* If the commit fixes a bug on the [http://bugs.gramps-project.org bug tracker], the summary shall include the bug ID and summary from the tracker.
* The summary should be separated from the body of the message by a single blank line.
* Messages should attempt to describe how the change affects the functionality from the user's perspective.
* It is not necessary to describe minute details about the change nor the files that are affected because that information is already stored by Subversion.* If the commit fixes a bug on the [http://bugs.gramps-project.org bug tracker], the log message shall include the bug ID and summary from the trackerGit.* When committing contributed code, the log message shall list author should be credited using the contributor's name and email--author option.
You can see the last changes with the svn git log command, an example usage of this command: svn git log -r BASE:10240 | head -n 40Change 10240 to a more recent version to have the command take less time.oneline
You can also limit the number of entries shown by passing in the '''--limitn''' flag to svn. Add '''-v-stat''' to see the files affected by the commit:
==Adding new files==
All the files with the translatable strings '''must''' be listed in the po/POTFILES.in or po/POTFILES.skip files. This means that most new files must have their names added to these files.
===Check===
where ../.. is the path to your local copy
==Removing files==
Remember to remove references to the file from the po/POTFILES.in and Makefilepo/POTFILES.am skip files.
==Bugfixes in branches==
Whenever a bug is fixed in a maintenance branch, it is the committer's responsibility to make sure the fix is also committed to the trunk. This can be accomplished using one of three methods. All methods require a working copy of trunk and the branch. ===Using svn merge===The most common way to move changes between branches is by using the svn merge command. Assuming you have a working copy of trunk in ~/gramps/trunk and a working copy of the 3.3 branch in ~gramps/gramps{{stable_branch}}: gramps{{stable_branch}}$ svn commit gramps{{stable_branch}}$ cd ../trunk trunk$ svn merge -c REVISION https://gramps.svn.sourceforge.net/svnroot/gramps/branches/maintenance/gramps{{stable_branch}}/ trunk$ svn commit ===Using svn diff===You can also create a patch on gramps{{stable_branch}} branch and apply it to trunk: gramps{{stable_branch}}$ svn diff -r PREV > ~/mypatch.patch gramps{{stable_branch}}$ cd ../trunk trunk$ patch -p0 < ~/mypatch.patch Then you may have to fix things that could not be applied due to conflicts. The patch program would mark the conflicts with the <<<<<<, ======, and >>>>>> signs. You will then need to commit your changes: trunk$ ./svnci ===Manually===Make the change in the branch. Commit the change to the master branch. Make the change in trunk. Commit the change to trunk. More info: http://svnbook.red-bean.com/
[[Category:Developers/General]]