Subversion 1.1.3 was released last week. This is a follow up to the 1.1.2 release that fixes the compilation of the perl bindings.
If you use SVK, want to update Subversion, and tend to build your own software, then you need to grab this release from the Subversion site download area.
I thought it would be fun to sit down and figure out what my top 10 guitar songs would be. These are the songs when I listen to them, make me want to just pick up the guitar.
The day that I convince Jonna to move to an island with nothing but a boom box, and a life supply of Ramen noodles, a mix CD with these 10 songs would do it for me.
#1: The two solos in this song are the best guitar solos ever written, in my opinion.
#5: The outtro solo in this song is one of my favorite Zakk Wylde solos. Don’t know what it is about this one, but it hits you right in the gut.
#9: The solo in Hot For Teacher is, in my opinion, Eddie Van Halens best solo. Eruption is way cool, don’t get me wrong, but this one takes the cake. The rest of the song I could do without, but the solo kicks some butt.
I think I’m a pretty big fan of certain musicians and would definitely call myself a movie buff. But after this morning I’m not sure I can really use the word “fan” to describe my love of music or movies.
Reading slashdot this morning, there was an article about a guy who is waiting five months in line at the theater for Star Wars Episode III tickets. Even stranger, the guy is keeping a blog, apparently right from his place in line.
I do not think that I could like anything to the point where I would camp out for 139 days for tickets. If I can’t buy the CD on amazon.com, or can’t buy the tickets somewhere like Ticketmaster or Fandango, chances are you won’t be getting me to listen to your music, see your concert, or watch your movie.
Then again, I might be an extreme. If the line is too long at McDonalds the first thought that comes to mind is “Maybe I’ll eat tomorrow …”.
My youngest brother Glen turns 27 today. Happy Birthday!
If you get bored here, check out his blog, Netdudes Notes.
Mike Hearn is a developer for the Wine project and currently researching using SVK to organize his work. He is maintaining a page on the SVK Wiki to document his experiences with the tool.
According to vai.com it looks like the new album is going to be out on February 22, 2005. Additionally, a U.S. Tour starts in March, with the band hitting Chicago on April 13th at the House of Blues.
The band this time around includes:
Steve Vai – Guitar / Vocals
Billy Sheehan- Bass
Tony MacAlpine – Guitar / Keyboards
Dave Weiner – Guitar
Jeremy Colson – Drums
Along with being a huge Vai fan for as far back as I can remember, I’ve also been a huge Tony MacAlpine and Billy Sheehan fan as well, and am really looking forward to the chance to see this incarnation of the band live on stage. All of them are just incredible musicians.
Along with this tour, there is a package you can buy called “The Evo Premium Experience” in which you also get the following along with your regular tickets (taken directly from vai.com):
Sure its a little extra (ok, a lot extra), but how many times do you really get a chance to watch Steve Vai and Billy Sheehan do a soundcheck together and attend a Q&A session with one of your favorite musicians of all time? If that wasn’t cool enough, add to it having your favorite woman of all time sitting right there with you through the whole thing.
This is one concert that I’m definitely looking forward to, even though the House of Blues isn’t exactly my favorite place to see a concert. The last time I saw Vai at the House of Blues (on the Fire Garden Tour) I wound up way in back watching the concert on the TV screens.
Hopefully, the seats will be a little better this time …
Yesterday we were out at Spring Hill Mall and made our usual obligatory stop at SunCoast when we found Millennium: The Complete Second Season sitting out in the new releases section. We also found The X-Files – The Complete First Season for half off. The X-Files is another one of those shows we really liked, but the DVD sets have just been too expensive to buy.
This comes on the heels of finding Quantam Leap Season 2 in stores as mentioned previously. I think we’re covered as far as the “500 channels and nothing to watch but reality TV” syndrome that we’ve been suffering from lately.
I think the release of old TV favorites is probably my favorite part of the DVD revolution. I find it so cool to be able to sit down whenever I feel like it and pop in one of these shows.
Quantum Leap – The Complete Second Season was released recently to DVD. This was my favorite show "back in the day", and I would make sure I was home to watch it every Wednesday. I just didn’t know what to do when it switched to Friday’s and was on at the same time as Americas Most Wanted – my other favorite show at the time.
Boy, this reminds me of the time when watching TV was actually something you looked forward to doing. I’m SO tired of reality TV shows at this point. It’s all you find these days …
Last week we explored using a local branch and keeping it in sync with the main repository. We also explored the incremental synchronization of local mirrors on our machine. This week we will be merging our changes back into the main repository and wrapping up our discussion of SVK for now.
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.
At the end of our last article, we had finished the work that we wanted to do and now we would like to merge our changes into the main repository so that others can access our changes. The assumption is that we have performed all of the due dillegence that software developers perform when they finalize a change and are ready to have those changes activated in the main repository, including keeping our local branch up to date with the main repository using the repository synchronization techniques outlined in previous articles and merging them into our local branch to keep our workarea current.
The time has finally come where everyone who uses the main repository gets to see the changes we have been working on.
When merging to a mirrored tree in SVK, we use the smerge command just like we would in our previous work, only this time the source and destination are switched. We are now merging to the mirror, however the process looks the same. The really cool thing about SVK however, is that when you perform a merge to a mirrored path, you not only update your mirror, but the repository that the mirror points to is also updated simultaneously.
So lets do it. Before actually performing the merge, connect to the network and sync your local repository.
svk sync //bieberlabs/trunk
Syncing http://subversion.bieberlabs.com/svn/bieberlabs/trunk
rbieber:/~>
Now that we are synced up, we will perform an svk smerge -C command to make sure we have no conflicts.
rbieber:/~>svk smerge -C //bieberlabs/new-feature-x _
//bieberlabs/trunk
Auto-merging (0, 409) /bieberlabs/new-feature-x _
to /bieberlabs/trunk (base /bieberlabs/trunk:408).
Checking locally against mirror source _
http://subversion.bieberlabs.com/svn/bieberlabs/trunk.
U website/index.php
D website/familypictures
New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _
/bieberlabs/new-feature-x:409
rbieber:/~>
Some things to notice. Previously we saw quite a few changes coming from the mirrored repository to our local branch, including the re-adding of a photos directory with 68 pictures in the main repository. None of these changes are being merged back to the mirror. SVK is keeping track of the merges we have made from the main repository to our local branch and filtering them out (or skipping them) for us.
It winds up that with all the activity between the main repository and the local branch, the final result is that the only changes made by us in this whole process were the deletion of a directory, and modifications to our index.php file — and SVK knows that. We didn’t have to spend a lot of our valueable time towards an impossible schedule to figure it out!
Now that we know there are no conflicts (it’s nice to live in a perfect world!) we can actually perform a real merge to the mirror. We do this by substituting (in this case) the -C option with the -l option to get an initial log message that reflects each of our individual commits so we know what changes have been made through the time we have been developing on our local branch.
rbieber:/~>svk smerge -l //bieberlabs/new-feature-x //bieberlabs/trunk
Auto-merging (0, 409) /bieberlabs/new-feature-x to _
/bieberlabs/trunk (base /bieberlabs/trunk:408).
Waiting for editor...
Merging back to mirror source _
http://subversion.bieberlabs.com/svn/bieberlabs/trunk.
U website/index.php
D website/familypictures
New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _
/bieberlabs/new-feature-x:409
Merge back committed as revision 24.
Syncing http://subversion.bieberlabs.com/svn/bieberlabs/trunk
Retrieving log information from 24 to 24
Committed revision 420 from revision 24.
rbieber:/~>
As you can see from the above messaging, a few things have happened during the actual merge:
Just to verify that our changes made it to the repository, we can go to our local installation of ViewCVS to verify the commit:
In the last three articles, we have the basic areas of distributed, activity based development necessary to get someone new to SVK productive. I hope that as we have walked through the use of this tool, I have illustrated the huge gains you can receive from beginning to use it.
There are obvious areas in which I have neglected to cover from a conceptual level like conflict resolution, however this process under SVN is covered quite extensively in the Resolving Conflicts chapter of the SVN book written by the Subversion developers. There are also other commands and types of merges that SVK can perform that I will leave to the reader to explore.
SVK is a very powerful tool. The main disadvantage of it is that is written in PERL, and therefore can be difficult to install, and slow to start up. However, these disadvantages are far outweighed by the advantages that the tool brings to the table.
The ability to work while disconnected from a central repository and the automatic merge tracking features of SVK are of incredible value to anyone wanting to give flexibility and true distributed capabilities to their development staff. I highly recommend that you take the time to explore this tool and explore for yourself the new capabilities and flexibility, not to mention just plain time savings SVK brings to the table.
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.
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.
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
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.
Bieber Labs 