On Mon, Apr 21, 2008 at 12:23 AM, Mathijs Romans <mathijs_at_romansland.nl>
wrote:
> Hi!
>
> we have a typical setup where trunk is our stable version and
> developing takes place in several branches. While development in a
> brach takes place, the trunk may be updated with other changes. Now
> suppose we want to merge one of these development branches back into
> the trunk, we prefer to test it before we include it in the trunk. So
> my idea was to first update the branch with all changes that have
> taken place in the trunk. And if it works, to apply all changes in the
> branch directly back into the trunk.
>
> Now of course, in principle I'll be applying the changes in the trunk
> twice. In the book Version Control with Subversion, it says:
>
> "When patching a file, Subversion typically notices if the file
> already has the change, and does nothing."
>
> Now my question is this: in the case the merge is a diff between
> versions A and B, applied to version X, if a file is identical in B
> and X, is it guaranteed that the merge does nothing to it in all
> cases? Or is "typically" still the right quantifier here? Is it then
> probably best to make a "testing" branch to test merged components?
>
When you merge from 'branch' to 'trunk' and if the files are identical in
'branch' and 'trunk', then I am pretty sure that subversion will not do
anything when you merge to the working copy of your trunk.
This scenario, obviously, happens when that file did not change in the
branch. And any change to that file, if any, would have been merged to the
branch when you first merged from trunk to branch.
I will add that, there is no harm in trying out. You don't need to create a
new 'testing' branch. When you merge, it affects only your working copy. You
can (should) review the result of the merge in the working copy and decide
if subversion did the right thing. Only after that should you check in the
changes.
regards,
-Hari
Received on 2008-04-22 08:01:37 CEST