Changes between Version 12 and Version 13 of pm-svn-branches


Ignore:
Timestamp:
Feb 19, 2011 12:46:21 PM (11 years ago)
Author:
stefan
Comment:

replace COIN by COIN-OR; fix a few typos

Legend:

Unmodified
Added
Removed
Modified
  • pm-svn-branches

    v12 v13  
    77A '''''branch''''' is a specific "line" of code development.  One always has a main branch, which contains the main development branch.  In subversion, this main development branch is by convention called '''''trunk'''''.  But it is a very good idea, and we highly recommend this, to maintain stable branches, which allow the common user to work with a recent version of the code, without being disturbed by every single change and intermediate unstable version.  The recommended way to handle a project's repository in terms of stable branches and official point releases is discussed [wiki:pm-svn-releases here].
    88
    9 In the trunk development branch one can safely continue to work, possily sharing the changes with other developers, and if a new stable version has been obtained, the changes can be '''''merged''''' to a stable branch.
     9In the trunk development branch one can safely continue to work, possibly sharing the changes with other developers, and if a new stable version has been obtained, the changes can be '''''merged''''' to a stable branch.
    1010
    1111If you have used CVS before, you know the notion of "branches" and "tags".  In CVS, there are specific commands to organize tags and branches, which can sometimes be confusing.  It is important to understand that subversion works in a different, much easier way.
    1212
    13 Subversion itself does not know about tags and branches.  Instead, one can use the fact that subversion (in constrast to CVS) also keeps revisions of directories, just as for files, and that an {{{svn copy}}} retains the change history for copied files and directories.
     13Subversion itself does not know about tags and branches.  Instead, one can use the fact that subversion (in contrast to CVS) also keeps revisions of directories, just as for files, and that an {{{svn copy}}} retains the change history for copied files and directories.
    1414
    15 '''Project managers are encouraged to follow the [wiki:pm-svn-releases COIN release management policy].'''  In this case, the directory structure in the svn repository at the very base of a project (say, {{{Prjct}}}), is
     15'''Project managers are encouraged to follow the [wiki:pm-svn-releases COIN-OR release management policy].'''  In this case, the directory structure in the svn repository at the very base of a project (say, {{{Prjct}}}), is
    1616{{{
    1717Prjct ---- trunk
     
    5252Revision: 450
    5353Node Kind: directory
    54 Last Changed Author: joedoe
     54Last Changed Author: johndoe
    5555Last Changed Rev: 443
    5656Last Changed Date: 2006-07-20 10:49:03 -0400 (Thu, 20 Jul 2006)
     
    7979=== Summary ===
    8080
    81 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''' 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.
     81The subversion repository is essentially a large file system with revision control.  One can check out directories (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.
    8282
    8383== Merging Branches ==
    8484
    85 '''Please make sure you read the [wiki:pm-svn-releases page about the COIN policy of handling releases and stable branches].'''
     85'''Please make sure you read the [wiki:pm-svn-releases page about the COIN-OR policy of handling releases and stable branches].'''
    8686
    87 === Synchonizing two branches ===
     87=== Synchronizing two branches ===
    8888
    8989After 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.
     
    9797This 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]).
    9898
    99 Note: 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.'''
     99Note: Once you have successfully synchronized {{{stable/2.5}}} with {{{trunk}}}, you should commit the changes in {{{stable/2.5}}} and '''include the current repository number in your commit message, so that you know the beginning point for your next merge operation.'''
    100100
    101101=== Applying a changeset to a different branch ===
     
    105105svn merge -r 465:466 https://projects.coin-or.org/svn/Prjct/trunk
    106106}}}
    107 in your local working copy of {{{stable/2.5}}}.  This will try to merge the changeset 466 into your local copy.  If the files to which changes are applied have not divergted too much, this should work without problems, but you should check in any case if the patch is applied correctly.
     107in your local working copy of {{{stable/2.5}}}.  This will try to merge the changeset 466 into your local copy.  If the files to which changes are applied have not diverged too much, this should work without problems, but you should check in any case if the patch is applied correctly.