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?
I appreciate your comment.
Kind regards,
Mathijs Romans
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-22 09:37:49 CEST