Oh, /now/ I'm beginning to understand. So, when I delete the branch and
copy over the trunk, I have to merge into this same branch using -r
<revision that started the "old" branch>:<revision before creation of
the "new" branch>. I think this time I got it. Thanks for your patience!
You and the entire Subversion team continue to amaze me, I think many
OSS and proprietory projects would benefit if they use Subversion as a
case study.
kfogel@collab.net wrote:
>"Sergey A. Lipnevich" <sergey@optimaltec.com> writes:
>
>
>>Yes it does, thanks! My only concern here is that in the middle of
>>rebranching I'd have to save and then reapply changes that didn't make
>>it to the trunk.
>>
>>
>
>You don't have to save them -- they're already saved in the
>repository, in the old version of your branch.
>
>
>
>>I guess the decision on the merge strategy has to be
>>made on a per-project basis. In a corporate setting, I'd be reluctant
>>to use Subversion's rebranching, out of fear of losing unmerged
>>changes (it's more difficult to explain this to team members to begin
>>with).
>>
>>
>
>The only kind of change you ever need to fear losing is an uncommitted
>one, and that's true no matter what kind of branching scheme you're
>using. Of the two branching schemes we're discussing, neither
>involves saving uncommitted changes in a working copy while some other
>operation is performed.
>
>-K
>
>
Received on Tue Aug 12 23:35:15 2003