User Tools

Site Tools


subversion-howto

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
subversion-howto [2009/06/19 14:50] bpsubversion-howto [2010/11/20 12:38] (current) – Added note about cheap copies when branching. bp
Line 123: Line 123:
 svn cp trunk branches/mybranch svn cp trunk branches/mybranch
 </code> </code>
-Of course, this will include the full OOFEM, but there's no harm in doing so. +Of course, this will include the full OOFEM, but there's no harm in doing so. Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data.
-Creating the branch directly on the server+
  
 You can also create the branch directly without having a checked-out working copy: You can also create the branch directly without having a checked-out working copy:
Line 161: Line 160:
 How do I merge the latest patches added to the trunk in my development branch? How do I merge the latest patches added to the trunk in my development branch?
  
-Suppose that you want to synchronize your development branch branches/mydevs with the trunk. Subversion is aware of the history of your branch and knows when it divided away from the trunkTo replicate the latest, greatest trunk changes to your branch, first make sure your working copy of the branch is “clean”that it has no local modifications reported by svn statusThen simply run: +First, always remember to do your merge into a working copy that has no local edits and has been recently updatedIf your working copy isn'“clean” in these ways, you can run into some headaches. Assuming your working copy is tidy, merging isn't a particularly high-risk operation. If you get the merge wrong the first time, simply svn revert the changes and try again. 
-<code> +If you've merged into a working copy that already has local modifications, the changes applied by a merge will be mixed with your pre-existing ones, and running svn revert is no longer an option. The two sets of changes may be impossible to separate.
-$ pwd +
-/home/user/my-oofem-branch+
  
-svn merge http://www.oofem.org/svn/trunk + 
---- Merging r345 through r356 into '.'+It's time to use the svn merge command. This command, it turns out, is a very close cousin to the svn diff command (which you read about in Chapter 2, Basic Usage). Both commands are able to compare any two objects in the repository and describe the differences. The svn merge command is almost exactly the same. Instead of printing the differences to your terminal, however, it applies them directly to your working copy as local modifications. 
-U    button.c + 
-U    integer.c+**But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal  of trunk changes that never happened on your branch. 
 +** 
 + 
 +To express only the changes that happened on your branch, you need to compare the initial state of your branch to its final state. Using svn log on your branch, you can see that your branch was created in revision 341. And the final state of your branch is simply a matter of using the HEAD revision. That means you want to compare revisions 341 and HEAD of your branch directory, and apply those differences to a working copy of the trunk. 
 + 
 +A nice way of finding the revision in which a branch was created (the “base” of the branch) is to use the --stop-on-copy option to svn log. The log subcommand will normally show every change ever made to the branch, including tracing back through the copy which created the branch. So normally, you'll see history from the trunk as well. The --stop-on-copy will halt log output as soon as svn log detects that its target was copied or renamed. 
 + 
 +So in our continuing example, 
 +<code> 
 +$ svn log -v --stop-on-copy \ 
 +          http://www.oofem.org/svn/branches/my-branch 
 + 
 +------------------------------------------------------------------------ 
 +r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines 
 +Changed paths: 
 +   A /branches/my-branch (from /trunk:340) 
 +$
 </code> </code>
-This basic syntax—svn merge URL—tells Subversion to merge all recent changes from the URL to the current working directory (which is typically the root of your working copy)After running the prior exampleyour branch working copy now contains new local modifications, and these edits are duplications of all of the changes that have happened on the trunk since you first created your branch:+As expected, the final revision printed by this command is the revision in which my-branch was created by copying. 
 +Here'the final merging procedurethen:
 <code> <code>
 +$ cd my-branch
 +$ svn update
 +At revision 405.
 +
 +$ svn merge -r 341:405 http://www.oofem.org/svn/trunk
 +U   integer.c
 +U   button.c
 +U   Makefile
 +
 $ svn status $ svn status
-     +  integer.c 
-     button.c +  button.c 
-     integer.c+  Makefile 
 + 
 +# ...examine the diffs, compile, test, etc... 
 + 
 +$ svn commit -m "Merged trunk changes r341:405 into the my-branch." 
 +Sending        integer.c 
 +Sending        button.c 
 +Sending        Makefile 
 +Transmitting file data ... 
 +Committed revision 406.
 </code> </code>
-At this point, the wise thing to do is look at the changes carefully with svn diff, and then build and test your branch. Notice that the current working directory (“.”) has also been modified; the svn diff will show that its svn:mergeinfo property has been either created or modified. This is important merge-related metadata that you should not touch, since it will be needed by future svn merge commands. (We'll learn more about this metadata later in the chapter.) 
  
-After performing the merge, you might also need to resolve some conflicts (just as you do with svn update) or possibly make some small edits to get things working properly(Rememberjust because there are no syntactic conflicts doesn'mean there aren't any semantic conflicts!) If you encounter serious problems, you can always abort the local changes by running svn revert -R (which will undo all local modifications) and start a long “what'going on?” discussion with your collaboratorsIf things look good, however, you can submit these changes into the repository:+**Notice that the commit log message very specifically mentions the range of changes that was merged into the trunk. Always remember to do thisbecause it's critical information you'll need later on. 
 +** 
 +For example, suppose you decide to keep working on your branch for another week, in order to complete an enhancement to your original feature or bug fix. The repository's HEAD revision is now 480, and you're ready to do another merge from your private branch to the trunkBut as discussed in the section called “Best Practices for Merging”you don'want to merge the changes you've already merged before; you only want to merge everything “new” on your branch since the last time you mergedThe trick is to figure out what'new. 
 + 
 +The first step is to run svn log on the trunkand look for a log message about the last time you merged from the branch:
 <code> <code>
-$ svn commit -m "Merged latest trunk changes to my-oofem-branch." +$ cd my-branch 
-Sending        +$ svn log 
-Sending        button.c+… 
 +------------------------------------------------------------------------ 
 +r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line 
 + 
 +Merged my-branch changes r341:405 into the trunk
 +------------------------------------------------------------------------ 
 +… 
 +</code> 
 + 
 +Aha! Since all branch-changes that happened between revisions 341 and 405 were previously merged to the trunk as revision 406, you now know that you want to merge only the branch changes after that—by comparing revisions 406 and HEAD. 
 +<code> 
 +$ cd my-branch 
 +$ svn update 
 +At revision 480
 +</code> 
 +# We notice that HEAD is currently 480, so we use it to do the merge: 
 + 
 +<code> 
 +$ svn merge -r 406:480 http://www.oofem.trunk/svn/trunk 
 +U   integer.c 
 +U   button.c 
 +U   Makefile 
 + 
 +$ svn commit -m "Merged trunk changes r406:480 into the my-branch."
 Sending        integer.c Sending        integer.c
-Transmitting file data .. +Sending        button.c 
-Committed revision 357.+Sending        Makefile 
 +Transmitting file data ... 
 +Committed revision 481. 
 +</code> 
 + 
 + 
 +Now the trunk contains the complete second wave of changes made to the branch. At this point, you can either delete your branch (we'll discuss this later on), or continue working on your branch and repeat this procedure for subsequent merges. 
 + 
 +=== Merging a branch to the trunk === 
 +At some point, you'll be ready to merge the “synchronized” feature branch back to the trunk. To do this, begin by doing a final merge of the latest trunk changes to the branch. When that's done, the latest versions of branch and trunk will be absolutely identical except for your branch changes. So in this special case, you would merge by comparing the branch with the trunk: 
 +<code> 
 +$ cd trunk-working-copy 
 + 
 +$ svn update 
 +At revision 1910. 
 + 
 +$ svn merge http://www.oofem.org/svn/trunk@1910 \ 
 +            http://www.oofem.org/svn/branches/my-branch@1910 
 +U  real.c 
 +U  integer.c 
 +A  newdirectory 
 +A  newdirectory/newfile 
 +
 </code> </code>
-At this point, your private branch is now “in sync” with the trunk, so you can rest easier knowing that as you continue to work in isolation, you're not drifting too far away from what everyone else is doing.+By comparing the HEAD revision of the trunk with the HEAD revision of the branch, you're defining a delta that describes only the changes you made to the branch; both lines of development already have all of the trunk changes.
  
  
Line 260: Line 340:
  
  
-The definite information can be found on the Subversion project page http://subversion.tigris.org/ and in the online Subversion book http://svnbook.red-bean.com/.+The definite information can be found on the Subversion project page http://subversion.tigris.org/ and in the online Subversion book http://svnbook.red-bean.com/The oofem svn repository server is based on version 1.4, the corresponding version of svn book can be found here http://svnbook.red-bean.com/en/1.4
subversion-howto.1245415845.txt.gz · Last modified: 2009/06/19 14:50 by bp