noresm:svnbestpractice

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
noresm:svnbestpractice [2014-04-03 09:52:29]
alfg [Tags] 		noresm:svnbestpractice [2022-05-31 09:29:32] (current)
Line 4: Line 4:
  
 Follow this link to find the tutorial: [[NORESM:SvnTutorial]] Follow this link to find the tutorial: [[NORESM:SvnTutorial]]
 +
 +**Note: As of November 13th 2015, NorESM uses git as version control system. The rules and guidelines for merging/branching, tags and branch names are still valid in the new system**
  ===== Branches =====  ===== Branches =====
  
Line 18: Line 20:
 Create a branch with (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html) Create a branch with (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html)
 <file> <file>
-$ svn copy http://svn.example.com/repos/calc/trunk \+  svn copy http://svn.example.com/repos/calc/trunk \
            http://svn.example.com/repos/calc/branches/my-calc-branch \            http://svn.example.com/repos/calc/branches/my-calc-branch \
            -m "Creating a private branch of /calc/trunk."            -m "Creating a private branch of /calc/trunk."
 +</file>
 +or specifically for the NorESM repository with
 +<file>
 +  svn copy https://svn.met.no/NorESM/noresm/tags/trunk2.0-1 \
 +           https://svn.met.no/NorESM/noresm/branches/privateMYPORJECT_trunk2.0-1 \ 
 +           -m "Creating a project branch of tags/trunk2.0-1." 
 </file> </file>
  
Line 26: Line 34:
 <file> <file>
 svn checkout $BRANCHURL nameOfBranchOnMyPC svn checkout $BRANCHURL nameOfBranchOnMyPC
 +</file>
 +
 +
 +In git: First create your new branch locally and then make the remote aware of the new branch like so: 
 +<file>
 +git checkout -b my_branch_name
 +git push -u origin my_branch_name
 +</file>
 +
 +..and make sure your .gitconfig-file is configured for doing a merge (for example):
 +<file>
 +[merge]
 +    tool = vimdiff
 +[diff]
 +   tool = vimdiff
 </file> </file>
  
Line 95: Line 118:
 If your code does not pass the tests, you can **not** merge your code back to the trunk If your code does not pass the tests, you can **not** merge your code back to the trunk
  
-Note that in svn, **you can only merge ONE time from your branch to the trunk**, or you risk making a mess of the system! (See http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html ==> "Reintegrating a branch", note the statement **Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work"**)+Note that in svn, **you can only merge ONE time from your branch to the trunk**, or you risk making a mess of the system! (See http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html ==> "Reintegrating a branch", note the statement **Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work"**). N.B. There is a workaround to this, described in http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
  
 The merge command (from trunk) will be something like (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html)  The merge command (from trunk) will be something like (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html) 
 <file> <file>
 svn merge --reintegrate $BRANCHURL svn merge --reintegrate $BRANCHURL
 +</file>
 +
 +Using git, just use
 +<file>
 +git merge branchNameIWantToMergeWith
 </file> </file>
 ===== Tags ===== ===== Tags =====
Line 113: Line 141:
 Create the tag with a command like (http://svnbook.red-bean.com/en/1.6/svn.branchmerge.tags.html) Create the tag with a command like (http://svnbook.red-bean.com/en/1.6/svn.branchmerge.tags.html)
 <file> <file>
-svn copy http://svn.example.com/repos/calc/trunk \+  svn copy http://svn.example.com/repos/calc/trunk \
            http://svn.example.com/repos/calc/tags/release-1.0 \            http://svn.example.com/repos/calc/tags/release-1.0 \
            -m "Tagging the 1.0 release of the 'calc' project."            -m "Tagging the 1.0 release of the 'calc' project."
 +</file>
 +or specifically for the NorESM repository with 
 +<file> 
 +  svn copy https://svn.met.no/NorESM/noresm/trunk \
 +           https://svn.met.no/NorESM/noresm/tags/trunk2.0-2 \ 
 +           -m "Creating new tag of trunk." 
 </file> </file>
  
Line 121: Line 155:
  
 You should create a tag in the following cases: You should create a tag in the following cases:
-  * When you want to create a branch! **Always tag the model first and then create the branch from the tag**.+  * When you want to create a branch! **Always tag the model first and then create the branch from the tag**. (If a tag has already been made at the point where you want to branch off, you don't need to create a new tag!!)
   * A "released" version, a version which has been properly tested and which we recommend other users to run   * A "released" version, a version which has been properly tested and which we recommend other users to run
   * A version which has been used for some specific paper (maybe you want to do more runs after referee comments)   * A version which has been used for some specific paper (maybe you want to do more runs after referee comments)
 +
 +==== What tags exist? ====
 +
 +All tags are in https://svn.met.no/viewvc/noresm/noresm/tags/. Have a look there to find out which tags exist before you create a new tag. In order not to break the naming convension scheme, you need to know which tags exist already!
  
 ==== How should I name the tag? ==== ==== How should I name the tag? ====
Line 202: Line 240:
  
 ==== What should be stated in the commit message? ==== ==== What should be stated in the commit message? ====
 +
 +**Always state the JIRA issue associated with the work**! This makes the code changes pop up in JIRA!: For example "svn commit -m "NE-100: These are the fixes needed to solve this issue" " (see https://wiki.met.no/noresm/usingtheissuetracker)
  
 The commit message should include a concise description of the committed changes.  The commit message should include a concise description of the committed changes. 
Line 227: Line 267:
 Revision 198  Revision 198 
  
- changes made in r190...+ changes made in r198...
  
 Revision 193 Revision 193
  
- changes made in r190...+ changes made in r193...
  
 Revision 190 Revision 190
 +
 + changes made in r190...
 </code> </code>
  
Line 252: Line 294:
   changes made in r200 to branch featureMicomDevelopment...   changes made in r200 to branch featureMicomDevelopment...
 </code> </code>
- 
  • noresm/svnbestpractice.1396518749.txt.gz
  • Last modified: 2022-05-31 09:23:24
  • (external edit)