Here is a simple scenario – I have already merged changesets 45-55 from the trunk to branch b1. After this merge, more changes (56-60) were submitted into the trunk and I now need to merge those changes also to branch b1.
Which changesets do you select to merge ? 56-60, right ? Well, not exactly. It depends. If you are using Subversion merge command, you will need to specify 55-60. If you are using TortoiseSVN, you will select 56-60. You should keep this in mind if you are used to TortoiseSVN and you are attempting a merge using SVN merge command. Otherwise, you will end up with a merge without change 56.
Selecting changes to merge can become non-trivial when you don’t know which changes have already been merged. However, there is good news. With subversion 1.5, when you are selecting changes from source branch to merge into a target branch, don’t do it ! Subversion 1.5 onwards has built-in merge tracking. When using TortoiseSVN, if your intention is to merge all changes, just leave the changeset selection blank. Subversion knows which ones have already been merged and which ones to merge and it does it automatically. You can also select changes that have already been merged and those will be handled (excluded) automatically too.
There is a summary of what to expect from Subversion Merge-Tracking feature here – Subversion 1.5 merge-tracking in a nutshell.
There is detailed description of Subversion Merge-Tracking here and search for ‘mergeinfo property’ in Subversion documentation.
The above screen-shot shows the changes already merged in grey. Thanks to Subversion’s mergeinfo property.
So, can I just stop worrying about changesets altogether, when merging ? There are a few caveats to how mergeinfo metadata is (and sometimes not) recorded. Read this for more information - The Final Word on Merge Tracking.
Read about Subversion merging and branching here and TortoiseSVN merging documentation here – browse down to these sections : Reviewing the Merge Results and Merge Tracking.
, with the tool of your choice. Otherwise, it is can be an excruciatingly slow approach. The best part of this approach is that the interactions can be prototyped seemlessly and some of the feasibility doubts can be cleared early on. The problem with this approach is that the prototype can be mistaken as the actual product and the effort /scheduling expectations of the stakeholders can become hard to manage. Read Joel Spolsky’s brilliant observations on 
Win Advanced MVVM Book
I will dissect a Sample WPF MVVM application and then highlight the most important aspects of the MVVM by coding a brand new ViewModel and incorporating it into the application. You will learn about the Roles of the MVVM triad, the advantages of using MVVM and Characteristics of the ViewModel.
Attendees will be eligible to win
two copiesone copy (see below) of Josh Smith’s Advanced MVVM book as well as a few other WPF Books.{ I will be giving away one hard copy version of the book instead of digital versions due to concerns about DRM protection and unclear gift guidelines at lulu.com }.
And the winner is … Mark Freeman !!! Congratulations Mark, your copy of “Advanced MVVM” is on its way. Thanks for attending the code camp and your feedback.
Share This