Difference between revisions of "Committing policies"

From Gramps
Jump to: navigation, search
(Adding new files)
(Properties)
(5 intermediate revisions by 3 users not shown)
Line 33: Line 33:
 
  svn propset svn:eol-style native src/somefile.py
 
  svn propset svn:eol-style native src/somefile.py
 
  svn propset svn:keywords 'Id' src/somefile.py
 
  svn propset svn:keywords 'Id' src/somefile.py
 +
 +
====HOWTO setting the properties with git-svn ====
 +
Unfortunately, as of git-svn 1.8.1.2, there is no such thing as "git svn propset" yet, only "git svn propget" and "git svn proplist".
 +
To work this around, yet to avoid a full tree checkout, you can do a checkout of the subdirectory containing the new file(s) only
 +
in a temporary location, if you only work with SVN to work around this git-svn limitation.
 +
 +
For example, when I added gramps/gui/utilscairo.py on the gramps40 branch:
 +
 +
cd gramps/gui/
 +
git svn info | grep URL
 +
 +
This prints:
 +
''URL: svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/gramps/gui''
 +
Now,
 +
 +
cd /tmp
 +
svn checkout svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/gramps/gui
 +
cd gui
 +
svn propset svn:mime-type text/plain utilscairo.py
 +
svn propset svn:eol-style native utilscairo.py
 +
svn propset svn:keywords 'Id' utilscairo.py
 +
svn commit
  
 
==Removing files==
 
==Removing files==
Line 40: Line 62:
 
Whenever a bug is fixed in a 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.
 
Whenever a bug is fixed in a 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
+
===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.0 branch in ~gramps/gramps30:
+
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}}:
  gramps30$ svn commit
+
  gramps{{stable_branch}}$ svn commit
  gramps30$ cd ../trunk
+
  gramps{{stable_branch}}$ cd ../trunk
  trunk$ svn merge -c REVISION https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps30
+
  trunk$ svn merge -c REVISION https://gramps.svn.sourceforge.net/svnroot/gramps/branches/maintenance/gramps{{stable_branch}}/
 
  trunk$ svn commit
 
  trunk$ svn commit
  
;Using svn diff
+
===Using svn diff===
You can also create a patch on gramps30 branch and apply it to trunk:
+
You can also create a patch on gramps{{stable_branch}} branch and apply it to trunk:
  gramps30$  svn diff -r PREV > ~/mypatch.patch
+
  gramps{{stable_branch}}$  svn diff -r PREV > ~/mypatch.patch
  gramps30$  cd ../trunk
+
  gramps{{stable_branch}}$  cd ../trunk
 
  trunk$  patch -p0 < ~/mypatch.patch
 
  trunk$  patch -p0 < ~/mypatch.patch
  
Line 56: Line 78:
 
  trunk$  ./svnci
 
  trunk$  ./svnci
  
;Manually
+
===Manually===
 
Make the change in the branch. Commit the change to the branch.  
 
Make the change in the branch. Commit the change to the branch.  
  

Revision as of 12:56, 24 June 2013

Log messages

Every commit to Subversion 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:

  • 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 bug tracker, the log message shall include the bug ID and summary from the tracker.
  • When committing contributed code, the log message shall list the contributor's name and email.

You can see the last changes with the svn log command, an example usage of this command:

svn log -r BASE:10240 | head -n 40

Change 10240 to a more recent version to have the command take less time.

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 commit:

svn log --limit 5

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.

All 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.

Check

You can make a test on a local copy:

./autogen.sh
PYTHONPATH=../../trunk/src python po/test/po_test.py

where ../.. is the path to your local copy

Properties

You'll also need to set several properties for new files. For .py files, try the following:

svn propset svn:mime-type text/plain src/somefile.py
svn propset svn:eol-style native src/somefile.py
svn propset svn:keywords 'Id' src/somefile.py

HOWTO setting the properties with git-svn

Unfortunately, as of git-svn 1.8.1.2, there is no such thing as "git svn propset" yet, only "git svn propget" and "git svn proplist". To work this around, yet to avoid a full tree checkout, you can do a checkout of the subdirectory containing the new file(s) only in a temporary location, if you only work with SVN to work around this git-svn limitation.

For example, when I added gramps/gui/utilscairo.py on the gramps40 branch:

cd gramps/gui/
git svn info | grep URL

This prints: URL: svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/gramps/gui Now,

cd /tmp
svn checkout svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/gramps/gui
cd gui
svn propset svn:mime-type text/plain utilscairo.py
svn propset svn:eol-style native utilscairo.py
svn propset svn:keywords 'Id' utilscairo.py
svn commit

Removing files

Remember to remove references to the file from the po/POTFILES.in and Makefile.am files.

Bugfixes in branches

Whenever a bug is fixed in a 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/gramps52:

gramps52$ svn commit
gramps52$ cd ../trunk
trunk$ svn merge -c REVISION https://gramps.svn.sourceforge.net/svnroot/gramps/branches/maintenance/gramps52/
trunk$ svn commit

Using svn diff

You can also create a patch on gramps52 branch and apply it to trunk:

gramps52$  svn diff -r PREV > ~/mypatch.patch
gramps52$  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 branch.

Make the change in trunk. Commit the change to trunk.

More info: http://svnbook.red-bean.com/