Difference between revisions of "SVN Commit Tips"

From Gramps
Jump to: navigation, search
m
m (merge page)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Some procedural recommendations ==
+
#REDIRECT [[Brief_introduction_to_SVN]]
 
 
1. Always do ''svn up'' before a commit, and look especially for conflicts marked 'C'. If necessary get advice about handling conflicts.
 
 
 
2. Always do ''svn st'' and look for modifications 'M' that are unexpected or unintended. This is a *very important* sanity check. Checking the '?'
 
reports for forgotten additions is also worth remembering.
 
 
 
3. I personally prefer to explicitly name my commit targets via 'svn ci X Y Z ..', but if you do simply 'svn ci' (or use a utility commit script), it is especially important to:
 
 
 
(a) check advisory (2)
 
 
 
(b) quit (no save) your edit session if you see a filename you did not expect -- svn will prompt whether you want to abort or commit without a log entry (say 'abort').
 
 
 
'''And here are a couple of incidental suggestions'''
 
 
 
* avoid grouping unrelated changes; better to divide into separate commits for the following reasons: a better log entry; easier troubleshooting/reverting. (and probably more).
 
 
 
* similar to above, it may be better to make small incremental changes than one big one (if possible). Interim changes should not introduce breakage, of course.
 
 
 
* logs are important -- please give some thought to the log message: the ideal first sentence would be short, meaningful, and suggestive. Include a tracker issue #NNNN there, if appropriate. Additional explanation is encouraged if it would be something you yourself would appreciate when reading it six months from now. If relevant, emphasize impact of change from user's point of view.
 
 
 
..jgsack: well, those are my self-reminders anyway. Others may have other ways of saying it or other things to emphasize.
 
 
 
== svn merge ==
 
 
 
If you do a change in a branch, you need to do the same change in trunk. You can create a patch on the branch with
 
svn diff > mypatch.patch
 
and then apply the same patch on trunk.
 
patch -p0 < mypatch.patch
 
 
 
There is a more convenient way though: use svn merge. For this you commit your changes in the branch, and write down the revision number, eg a commit in branch{{stable_branch}} :
 
Transmitting file data ..
 
Committed revision 12345.
 
Now you apply this change in branch31 to trunk as follows. Go into your trunk working branch, and there type the command:
 
svn merge -c  12345 https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps{{stable_branch}}
 
The change will then be obtained and applied, after which you can commit trunk.
 
 
 
 
 
[[Category:Developers/General]]
 

Latest revision as of 00:21, 25 January 2013