kfogel@collab.net wrote:
>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?
>
Yes it is, thanks! The question was slightly different, however. Let's
say I create a branch by rev r16, then commit two revisions on branch,
r17 and r18, and merge r17 into trunk by revision r32, and then
"rebranch:" delete the branch (r33) and copy the trunk over (r34). The
change r18 is left out in the "old" branch. Now, I go to a branch root
and do a merge of r16:32, because I do not want to dig out what exactly
changes have been left out after merging with trunk and rebranching.
This merge is going to give me r17 changes back, now on the new branch,
that's for sure. But, is this merge going to create any conflicts, and
if yes, why? Is r17 going to introduce a conflict "with itself?"
>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'.
>
>
Saving changes with `svn diff' is difficult to explain to a non-caring
colleague who just wants the version control system to be out of the
way, so I'd prefer the scenario I described above, if it works.
Thanks for the explanations!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 19 21:23:54 2003