Changes between Version 9 and Version 10 of pm-svn-branches


Ignore:
Timestamp:
Oct 13, 2006 5:41:45 PM (14 years ago)
Author:
andreasw
Comment:

finished adaption to new policy (for now)

Legend:

Unmodified
Added
Removed
Modified

  • pm-svn-branches

    v9 v10  
    6868This will create a subdirectory {{{Coin-Prjct-stable-2.5}}} (or however you name it) in which you can work.
    6969
    70 At a later point you probably want to transfer the changes you made in the development branch over to the main release {{{trunk}}} branch.  For this you use {{{svn merge}}} as described further below.
     70At a later point you probably want to transfer changes between branches, for example, from the development branch {{{trunk}}} to a stable branch.  For this you use {{{svn merge}}} as described further below.
    7171
    72 Just as you create new branches with {{{svn copy}}}, you can create a tag by copying the version you want to tag into a subdirectory in the {{{tags}}} subversion repository directory, for example with
    73 
     72Just as you create new branches with {{{svn copy}}}, you can create a tag by copying the version you want to tag into a subdirectory in the {{{tags}}} subversion repository directory.  For example, say, you decided that what you want to make a new point release (number 2.5.6) from what you have currently in your stable branch {{{stable/2.5}}}.  Then you could issue the command
    7473{{{
    75 svn copy https://projects.coin-or.org/svn/Prjct/trunk \
    76          https://projects.coin-or.org/svn/Prjct/tags/ver-1-0-0 \
    77          -m "Creating tag ver-1-0-0
     74svn copy https://projects.coin-or.org/svn/Prjct/stable/2.5 \
     75         https://projects.coin-or.org/svn/Prjct/releases/2.5.6 \
     76         -m "Creating releases/2.5.6 from stable/2.5 (from rev 457)"
    7877}}}
    7978
    80 In contrast to CVS, you could now make modifications to the tagged version of your code (since subversion handles tags by convention simply as internal directories), but since tags are supposed to be a snapshot of the code at a particular time, that might not be good practice.
     79In contrast to CVS, you could now make modifications to the tagged version of your code (since subversion handles tags by convention simply as internal directories), but since tags are supposed to be a snapshot of the code at a particular time, that would be very bad practice.
    8180
    8281=== Summary ===
    8382
    84 The subversion repository is essentially a large file system with revision control.  One can check out directores (including subdirectories) at any level of that file system.  By convention, the root of the file system has the structure as in the above diagram.  The '''trunk''' always is the official release of the project, subdirectories in the '''branches''' directory correspond to branches, and subdirectories in the '''tags''' directory correspond to tags.
     83The subversion repository is essentially a large file system with revision control.  One can check out directores (including subdirectories) at any level of that file system.  By convention, the root of the file system has the structure as in the above diagram.  The '''trunk''' is the main development branch of the project, subdirectories in the '''stable''' and '''branches''' directories correspond to branches, and subdirectories in the '''releases''' and '''tags''' directories correspond to tags.
    8584
    8685== Merging Branches ==
    8786
    88 Typically, after you worked on your development branch for a while and want to make the current version in there the new official release for your project, you want to "merge" the changes you made in the branch into the '''trunk''' branch.  For this, you use the {{{svn merge}}} command.
     87'''Please make sure you read the [wiki:pm-svn-releases page about the COIN policy of handling releases and stable branches].'''
     88
     89=== Synchonizing two branches ===
     90
     91After you worked on your development branch ({{{trunk}}}) for a while, you might want to merge the changes you made into a stable branch, say {{{stable/2.5}}}.  For this, you use the {{{svn merge}}} command.
    8992
    9093An {{{svn merge}}} conceptually does an {{{svn diff}}} to get the difference between two copies of the code, and applies the difference as patch to the work copy, in which {{{svn merge}}} is performed, but it is more powerful than just obtaining the {{{diff}}} output and applying the patches yourself, since it will also rename and create files and directories, when this was within the changes that were done between the two copies.
    9194
    92 In the example of maintaining a development branch {{{devel}}} for the active code development, you will have created a new branch {{{devel}}} branch as described above.  ''You should write down somewhere, which the revision number was at which you split the development branch from the main {{{trunk}}} branch, or the revision number when you updated the official code release in {{{trunk}}} most recently.''  An easy way to do this is to include the revision number in the {{{commit}}} message when you first submit the new branch, or in the message for the {{{commit}}} when you submit the merges applied to the {{{trunk}}} version.  One way to find out the revision number of a working copy, is to type {{{svn update}}}.
     95As an example, assume that the current content in {{{stable/2.5}}} was the content of the development {{{trunk}}} corresponding to the repository revision 450 (e.g., you copied the {{{trunk}}} to {{{stable/2.5}}} at that revision, or you synchronized the two with a previous merge operation).  Now you want to update {{{stable/2.5}}} to the current state of {{{trunk}}}.  First, you need to have a local working copy of {{{stable/2.5}}}.  In the base directory of this working copy, you would then type
     96{{{
     97svn merge -r 450 https://projects.coin-or.org/svn/Prjct/trunk
     98}}}
     99This will merge then changes that occurred in {{{trunk}}} since revision 450 into your local copy (of {{{stable/2.5}}}).  If you have made no local modifications in {{{stable/2.5}}} (and it is a good idea do keep it that way), everything should just work fine.  If you have local modification in your {{{trunk}}} copy, you might encounter conflicts that you have to resolve, just as if you have done an {{{svn commit}}} and encountered conflicts (see the description of {{{svn commit}}} [wiki:pm-svn-cmds here]).
    93100
    94 Say now that you want to update the trunk version to reflect the changes you have made in your develepment branch.  The last change (or  the creation of the development branch) has happened at revision number 123.  In order to merge the changes that happened in the development branch {{{devel}}} into your local copy of the {{{trunk}}} version, you go into the base directory of the {{{trunk}}} version (e.g., {{{Coin-Prjct/trunk}}}, and there you type
    95 
    96 {{{
    97 svn merge -r 123 https://projects.coin-or.org/svn/Coin-Prjct/branches/devel
    98 }}}
    99 
    100 This will get all the changes that happened in {{{Coin-Prjct/branches/devel}}} since revision number 123 and apply those changes to your local copy of {{{trunk}}}.  If you have made no local modifications in {{{trunk}}} (and it is a good idea do keep it that way), everything should just work fine.  If you have local modification in your {{{trunk}}} copy, you might encounter conflicts that you have to resolve, just as if you have done an {{{svn commit}}} and encountered conflicts (see the description of {{{svn commit}}} [wiki:pm-svn-cmds here]).
     101Note: Once you have successfully synchronized {{{stable/2.5}}} with {{{trunk}}}, you should commit the changes in {{{sytable/2.5}}} and '''include the current repository number in your commit message, so that you know the beginning point for your next marge operation.'''