Bob,
I'm not really getting you. Initially I copy trunk to tags/pre-T34 and
branches/T34. Then I switch to branches/T34 and make my changes there.
As part of those changes, I want to have all the latest trunk in there,
so that I can minimize integration when things are merged from the
branch into the trunk. So I do a merge from the trunk for the missed
revisions since my branch was created into my working copy which points
to branches/T34. Once I commit (the changes that were originally made
to trunk, plus my local changes) to branches/T34, I want to switch to
trunk and merge the changes from the branches/T34 into my working copy
which points to the trunk.
Everything is working as expected for text files, but binary files cause
conflicts, which should not be there, since trunk has no local
modifications. No other changes occured for the files that were
conflicted, but there were other changes to other files (which is
inconsequential). I believe someone provided a good reproduction script
in another response.
Russ
Bob Hiestand wrote:
> Ryan,
>
> First, I think if you're keeping branches updated with the trunk,
> once you're ready to merge the branch back to the trunk, you should
> just merge based on current trunk and current branch head. Of course,
> if you only pick and choose changes to be put on the branch, this will
> not work.
>
> Second, while I'm not surprised that it's working the way you say,
> did any other change occur on the branch for the affected files?
>
> Thank you,
>
> bob
>
> On 10/18/06, Ruslan Sivak <rsivak@istandfor.com> wrote:
>> Ryan Schmidt wrote:
>> >
>> > On Oct 18, 2006, at 09:27, Ruslan Sivak wrote:
>> >
>> >> I'm not sure if I'm doing this correctly. Let's say you are working
>> >> on a branch. You want to get the latest changes from trunk because
>> >> you need/want them in your branch as well and in general want to make
>> >> sure that it will integrate cleanly with the trunk.
>> >>
>> >> It was my impression that if you do the same change twice, it will
>> >> just ignore it instead of creating a conflict. Perhaps its not the
>> >> same with binary files.
>> >>
>> >> So let's say you are switched to the branch and do a merge from trunk
>> >> for certain revisions that you want to catch up with.
>> >> After you get those changes into your branch, you test and make sure
>> >> everything works and then commit everything (including changes merged
>> >> from trunk) into your branch.
>> >>
>> >> Now you switch to trunk and merge in changes from the branch.
>> >> Theoretically, it should only end up merging whatever changes were
>> >> made to the branch, and since the changes that were merged from trunk
>> >> are already there, it should not modify those files.
>> >> Either I'm doing something wrong or this doesn't work correctly with
>> >> binary files, but I had a bunch of images which were updated in
>> >> trunk, merged to the branch, committed to the branch, merged back
>> >> into trunk, and they all caused conflicts. This is particularly
>> >> annoying as there doesn't seem to be a way to resolve these conflicts
>> >> in subclupse short of reverting which seemed to take forever.
>> >
>> > It should work. The fact that it's not suggests you may be running the
>> > wrong commands. Show us the commands you executed.
>> >
>> I'm using Subclipse. Here is an anonymized pseudolog.
>>
>> commit -m "image trunk update" F:/workspace/trunk/client/1ipod.jpg
>> Sending F:/workspace/trunk/client/1ipod.jpg
>> Transmitting file data ...
>> Committed revision 4016.
>>
>> merge -r4015:4016 svn://svn.somedomain.com/project/trunk
>> F:/workspace/T34
>> U F:/workspace/T34/client/1ipod.jpg
>> Merge complete.
>> ===== File Statistics: =====
>> Updated: 1
>>
>> commit -m "catching up to the trunk" F:/workspace/T34/1ipod.jpg
>> Sending F:/workspace/T34/1ipod.jpg
>> Transmitting file data ...
>> Committed revision 4017.
>>
>> merge svn://svn.somedomain.com/project/tags/pre-T34_at_HEAD
>> svn://svn.somedomain.com/project/branches/T34_at_HEAD F:/workspace/trunk
>> C F:/workspace/trunk/client/1ipod.jpg
>> Merge complete.
>> ===== File Statistics: =====
>> Conflicts: 1
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 20 22:15:57 2006