Changes

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: ===Summary===* The first line of the commit message should consist of a short summary of the change.* Maximum 70 characters.

===Description===* Messages The description should attempt be separated from the summary by a single blank line.* Attempt to describe how the change affects the functionality from the user's perspective.* Use complete sentences when possible.* It is not necessary to describe minute details about the change nor the files that are affected because that information is already stored by SubversionGit and can be viewed with "git diff".* If When committing contributed code, the commit fixes a bug on author should be credited using the [http://bugs.gramps-project.org bug tracker], the log message shall include the bug ID and summary from the tracker-author option.* When committing contributed codeIf you want to refer to another commit, use the log message shall list full commit hash. It will automatically be converted into a hyperlink by the contributor's name and emailGitHub web interface.Note: a 6 hexa digit hash enclosed in brackets WILL NOT WORK with GitHub auto-hyperlinking :-(

You ===Bug tracker integration===Special keywords can see the last changes with the svn log command, an example usage of this command: svn log -r BASE:10240 | head -n 40Change 10240 be used to a more recent version either link to have , or resolve, bug reports. They should be separated from the command take less timedescription by a single blank line.

You can also limit the number of entries shown by passing in the '''--limit''' flag to svn. Add '''-v''' to see the files affected by the commitTo resolve a bug or bugs use:

To link to a bug or bugs use: * Bug #12345* Issue #12345* Report #12345* Bugs #12345, #67890* Issues #12345, #67890* Reports #12345, #67890 For this to work, either the author or committer will need to be a developer on the Mantis bug tracker. The Git name must match either the Mantis username or real name, or the Git email must match the Mantis email. ==Adding new files=Useful commands===All You can see the files last changes with the translatable strings git log command, an example usage of this command: git log --oneline You can also limit the number of entries shown by passing in the '''-n'''mustflag to git. Add '''--stat''' be listed in to see the po/POTFILES.in file. This means that most new files must have their names added to that file.affected by the commit:  git log -5

All To credit the files that need to be released '''must''' be listed in the Makefile.am in the same directory. Please remember to do this for new files that you add to SVN.contributor of a patch, use:

You'll also need to set several properties for new files. For .py files, try the following: svn propset svn:mimegit commit -type text/plain src/somefile.py svn propset svn:eol-style native src/somefileauthor='A U Thor <author@example.py svn propset svn:keywords com>'Id' src/somefile.py

==Bugfixes in branchesAdding new files==Whenever a bug is fixed in a branch, it is All the files with the committertranslatable strings 's responsibility to make sure ''must''' be listed in the fix is also committed to the trunk<code>po/POTFILES.in</code> or <code>po/POTFILES.skip</code> files. This can be accomplished using one of three methods. All methods require a working copy of trunk and the branchmeans that most new files must have their names added to these files.

;Using svn mergeThe most common way Please remember to move changes between branches is by using the svn merge command. Assuming do this for new files that you have a working copy of trunk in ~/gramps/trunk and a working copy of the 3.0 branch in ~gramps/gramps30: gramps30$ svn commit gramps30$ cd ../trunk trunk$ svn merge -c REVISION https://gramps.svn.sourceforgeadd to Git.net/svnroot/gramps/branches/gramps30 trunk$ svn commit

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 changescan make a test on a local copy: trunk$ PYTHONPATH=../../svncigramps python po/test/po_test.py

;ManuallyMake the change in the branchwhere ../.. Commit is the change path to the branch. your local copy

Make ==Removing files==Remember to remove references to the file from the change <code>po/POTFILES.in trunk</code> and <code>po/POTFILES. Commit the change to trunkskip</code> files.