"Sergey A. Lipnevich" <sergey@optimaltec.com> writes:
> I suppose if I'm doing the merge and the change is already there it
> should simply do nothing. For example, when I merged from trunk back
> into branch, I effectively merged my changes with mine same changes,
> and SVN didn't complain as it shouldn't have. Why would I have to
> /selectively/ do it if I can do it all at once? Or can I? Thanks!
It's not the same, it only *looks* the same, until you try to do the
second merge -- then you start to have problems. This is very
important, so I'll try to give a clearer and more complete explanation
than I did before.
Suppose we do it your way:
1. Copy Trunk to Branch
2. Commit various changes to Branch
[meanwhile, other people are committing changes to Trunk]
3. Merge some (but not all) of the Branch changes to Trunk, commit.
4. Now merge *all* Trunk changes since step 1 into Branch. This
includes, of course, the Branch changes that were ported to
Trunk in step 3.
5. Continue development on Branch.
6. Merge all "remaining" changes to Trunk, that is, all changes in
Branch not previously merged to Trunk.
The problem now is that all those changes committed to Branch in step
4 show up as actual *changes* in Branch. So if any of those areas of
the code also changed in Trunk between steps 4 and 6, then you'll get
conflicts when you merge.
But if step 4 had been "delete Branch, recopy it from Trunk", then
there would be no problem, because although the same Trunk content
would be present in Branch as in your method, the content would not
show up as *changes* in Branch's history. The actual commits on
Branch would be only changes that are semantically related to the
purpose of the Branch -- and later, the merge back to Trunk will not
get any unecessary conflicts.
Your way commits many "changes" to the branch, but only some of those
changes are related to the work you're doing on the branch. Thus the
history is confusing to follow, and diffs hard to choose.
While these two goals are separate...
- Don't put non-changes into history as changes
- Don't generate unnecessary conflicts
... in practice they go together.
Is it clear now why you should delete your branch and rebranch (i.e.,
'svn cp') it from trunk, instead of merging many changes across from
trunk to the branch?
If you've already made changes in the branch since you merged the
changes from trunk, that's okay, you can port them over again after
recreating the branch. Changes in your working copy can of course be
saved with 'svn diff'.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 13 08:32:02 2003