In our last article, we installed SVK and created our local mirror of our repository. Since the writing of the previous article, we have caught up on a lot of TV by making code changes to our local SVK workarea and using the svk commit command to commit our changes to our local repository. During this time, one of my other personalities has been making code changes to our main repository using straight SVN. This scenario will illustrate keeping your local repository in sync, updating your local branch with changes to your mirrored repository, and merging your local changes back to your mirrored repository when we are finished.
Some of the lines in the command are truncated because they are too long. I have used the ‘_’ character as a line continuation character. If you see this character, look at the next line.
Keeping your mirror current
Some changes have happened in the main repository since we mirrored it, including changes to the main index.php file and a directory removal that was backed out from 8 revisions ago. We have also made some code changes to our local branch, including removing a familypictures directory and modifying the index.php file and now we want to sync our local branch with what is currently in production. To do this we have to update our mirrored repository, requiring a network connection. Once connected to the network, the svk sync command will bring down changes to the main repository to our local mirror just like it did in the first article, only quite a bit faster now since it is only pulling deltas from the last synchronization.
svk sync //bieberlabs/trunk Syncing https://subversion.bieberlabs.com/svn/bieberlabs/trunk Retrieving log information from 21 to 23 Committed revision 406 from revision 21. Committed revision 407 from revision 22. Committed revision 408 from revision 23.
Now our local mirror is current, so we can disconnect from the network again and go sit in front of the TV.
Keeping your local branch current
To make sure we are changing current code, we need to merge changes made to the main repository to our local branch. In straight SVN, this is done with the SVN merge command and specific revisions must be specified in order to make sure you are merging only changes that were made since your last merge from the trunk. This requires use of the SVN log command to figure out what you merged last in order to get the correct revision range to specify in the merge command.
With SVK, things get a little easier. SVK implements the star merge algorithm first introduced in the arch version control tool. This algorithm figures out what has already been merged from one branch to another, alieviating the need to go through and manually figure out what you need to merge back and forth to the branch.
The first thing we need to do in order to execute a star merge is the equivelent of a –dry-run merge in SVN. Using the -C option of the svk smerge command, we can find out whether there will be any conflicts during our merge to prepare ourselves for any conflict resolution that may have to take place.
svk smerge -C //bieberlabs/trunk //bieberlabs/new-feature-x Auto-merging (301, 408) /bieberlabs/trunk to /bieberlabs/new-feature-x (base /bieberlabs/trunk:301). U website/wordpress/index.php A website/photos A website/photos/raytracing A website/photos/raytracing/yinyang2.jpg A website/photos/raytracing/grapes.jpg A website/photos/raytracing/mexico-sunset.jpg A website/photos/raytracing/castle.jpg A website/photos/raytracing/yyisland.jpg A website/photos/jonna A website/photos/jonna/jonnaandyairhockey.jpg A website/photos/jonna/jonnajake.jpg A website/photos/jonna/jonnatattoo.jpg A website/photos/jonna/family.jpg A website/photos/jonna/ronandandyracing.jpg A website/photos/jonna/jonnaboys.jpg A website/photos/jonna/ronandbeetle.jpg A website/photos/jonna/andysbirthday.jpg A website/photos/jonna/jonna.jpg A website/photos/jonna/boysandpumpkins.jpg A website/photos/jonna/jonnacouch.jpg A website/photos/jonna/ronintn.jpg A website/photos/kelsi A website/photos/kelsi/kelsianddaddy.jpg A website/photos/kelsi/cute.jpg A website/photos/kelsi/girls1.jpg A website/photos/kelsi/kelsiandandrea.jpg A website/photos/kelsi/kelsiandandy.jpg A website/photos/kelsi/2minutes.jpg A website/photos/kelsi/kelsiandmommy.jpg A website/photos/kelsi/halloween.jpg A website/photos/kelsi/firstbirthday.jpg A website/photos/kelsi/toocool.jpg A website/photos/kelsi/batdadandbatkelsi.jpg A website/photos/kelsi/longhaireddaddy.jpg A website/photos/kelsi/ozzytatoo.jpg A website/photos/kelsi/newbaby.jpg A website/photos/kelsi/snowwhite.jpg A website/photos/kelsi/indeed!.jpg A website/photos/kelsi/kelsinow.jpg A website/photos/kelsi/computer.jpg A website/photos/kelsi/atthepool.jpg A website/photos/index.php A website/photos/uploaded A website/photos/uploaded/portraitweb.jpg A website/photos/uploaded/newTV.jpg A website/photos/uploaded/ronjonnaedsidcheyney1.jpg A website/photos/uploaded/signlicense.jpg A website/photos/uploaded/newtatto.jpg A website/photos/uploaded/wedding-picture-web.jpg A website/photos/uploaded/neutralzone.jpg A website/photos/uploaded/house-front.jpg A website/photos/uploaded/happy kelsi.jpg A website/photos/uploaded/house-left.jpg A website/photos/uploaded/biography-cover-jacob.jpg A website/photos/uploaded/mvc-007s.jpg A website/photos/uploaded/jonna-tattoo.jpg A website/photos/uploaded/biography-cover-andrew.jpg A website/photos/uploaded/ronring.jpg A website/photos/uploaded/house-downstreet.jpg A website/photos/uploaded/bridekiss.jpg A website/photos/uploaded/conehead kids.jpg A website/photos/uploaded/familyatdisney.jpg A website/photos/uploaded/biography-cover-ronjonna.jpg A website/photos/uploaded/rings.jpg A website/photos/uploaded/ronjonna.jpg A website/photos/uploaded/livingroom.jpg A website/photos/uploaded/andy and dwarf jonna.jpg A website/photos/uploaded/vaibox.jpg A website/photos/uploaded/andy books.jpg A website/photos/uploaded/kids.jpg A website/photos/uploaded/ronfirstbirthday.jpg A website/photos/uploaded/welcomemat.jpg A website/photos/uploaded/house-right.jpg A website/photos/uploaded/edcheyney2.jpg A qf/source/wildcard.h A qf/source/compress.h A qf/source/qfw32.c A qf/source/qf.c A qf/source/qf.h A qf/source/crc.h A qf/source/qfdos.c UU qf/source/QF2.MAK UU qf/source/DOSTYPES.H A qf/source/qfdos.h A qf/source/qfprint.c UU qf/source/DOC/QF.DOC UU qf/source/QFW32.MAK A qf/source/qfllf.8 A qf/source/wildcard.c A qf/source/qfos2.c A qf/source/compress.c UU qf/source/MAKEIT.CMD A qf/source/qfvfy.c UU qf/source/QF.MAK UU qf/source/QF.STS D qf/source/COMPRESS.C D qf/source/COMPRESS.H D qf/source/CRC.H D qf/source/QF.C D qf/source/QF.H D qf/source/QFDOS.C D qf/source/QFDOS.H D qf/source/QFLLF.8 D qf/source/QFOS2.C D qf/source/QFPRINT.C D qf/source/QFVFY.C D qf/source/QFW32.C D qf/source/WILDCARD.C D qf/source/WILDCARD.H New merge ticket: 4ddbc19d-f0cf-0310-94ad-fbf59656ec37:/trunk:23
As you can see from the output, we have about 110 changes that have happened to the main SVN repository since we created our local mirror, and all of them are now in our mirrored repository. Luckily during this time, none of the changes we have made to our local branch have conflicted with the changes made to the main repository.
One thing to note as we execute these commands is that the merge ‘from’ and merge ‘to’ repository locations on the command line are actually specified from left to right. The from repository is always the first one specified, and the ‘to’ repository is always specified last.
Now that we have this information, we can merge these changes into our local branch to continue our work. We do this with the same svk smerge command as above, this time without the -C option specified.
svk smerge -l //bieberlabs/trunk //bieberlabs/new-feature-x Auto-merging (301, 408) /bieberlabs/trunk to /bieberlabs/new-feature-x (base /bieberlabs/trunk:301). Waiting for editor... D qf/source/WILDCARD.H New merge ticket: 4ddbc19d-f0cf-0310-94ad-fbf59656ec37:/trunk:23 Committed revision 409.
You will notice that we specified an -l option to the smerge command. This command prepopulates your commit messages with the individual commit messages for the revisions you are merging and allows you to add additional message text to them. I find this very handy for keeping track of the actual changes that have been merged locally. The initial commit message when using this option during our merge looked like this:
r373@compaq (orig r13): rbieber | 2004-12-11T13:22:26.271503Z Change svn:eol-style to native r374@compaq (orig r14): rbieber | 2004-12-11T13:31:27.979404Z Continue updating header with GNU license. r375@compaq (orig r15): rbieber | 2004-12-11T13:36:57.421569Z Continue code reformatting r376@compaq (orig r16): rbieber | 2004-12-11T13:39:56.256824Z Rename files to lowercase equivelent r377@compaq (orig r17): rbieber | 2004-12-11T14:04:28.117857Z Code reformatting r379@compaq (orig r18): rbieber | 2004-12-11T14:24:48.136330Z Code reformatting r380@compaq (orig r19): rbieber | 2004-12-11T14:30:28.926752Z Code Reformatting r381@compaq (orig r20): rbieber | 2004-12-11T14:55:07.571027Z Code Reformatting r406@compaq (orig r21): rbieber | 2004-12-31T13:35:35.719204Z Update index.php with new content from production r407@compaq (orig r22): rbieber | 2004-12-31T13:37:40.697066Z Back out production changes made in revision 21 and update correct index.php r408@compaq (orig r23): rbieber | 2004-12-31T13:44:13.339651Z Undelete photos from old web site
Updating your working copy
Now we need to update our working copy from our local branch. We do this by changing to our working copy and executing an svk up command:
rbieber@compaq:~/svk/website> svk up Syncing //bieberlabs/new-feature-x/website (/bieberlabs/new-feature-x/website) in /home/rbieber/svk/website to 409. U wordpress/index.php A photos A photos/raytracing A photos/raytracing/yinyang2.jpg
This article has detailed the process of keeping your local mirror up to date with activity going on in your production Subversion repository. Keep in mind that all of the changes have happened on your local machine and that the main repository has not yet been updated. This process can be repeated as often as you like until such time as you are ready to merge your local changes back into the production repository, which will be covered in part 3 in this series. The real beauty of SVK that this article should illustrate is that at no time were we mining for specific revision ranges to merge. Using the smerge command this is all taken care of for us. The software knows about every merge that has happened between your local mirror and your local branches. When we smerge our changes back to the production repository, you will also not be mining for revision numbers. SVK knows what has been merged to your local branch and will automatically skip them on our merge back to the repository.
It is also very important to point out that the only time in which network connectivity was required was during the initial synchronization of the mirror (the execution of the svk sync command). All other actions were performed disconnected from any network.
In part 3, we will cover the final portion of our process, which is taking our local branch and merging our work back to the repository.