Bob,
The commands I ran (or rather subclipse's version of them) are already
included in this email. Ed Price also did a good job of providing a
replication script:
"Here is a simple cmdline reproduction (simplified, but hopefully still
valid):
$ svnadmin create repos
$ svn co file://`pwd`/repos wc
Checked out revision 0.
$ cd wc
$ echo "1" > foo
$ echo "2" > bar
$ svn add foo bar
A foo
A bar
$ svn ps svn:mime-type x/y foo bar
property 'svn:mime-type' set on 'foo'
property 'svn:mime-type' set on 'bar'
$ svn ci -m ""
Adding (bin) bar
Adding (bin) foo
Transmitting file data ..
Committed revision 1.
$ svn up
At revision 1.
$ echo "2" > foo
$ svn ci -m ""
Sending foo
Transmitting file data .
Committed revision 2.
$ svn up
At revision 2.
$ svn merge foo@1 foo@2 bar
C bar
$
The last conflict is the problem. If one removes the propset (so the
files are considered text), the merge does not produce a conflict.
"
Bob Hiestand wrote:
> Russ,
>
> Please provide exactly the commands you used to do each merge. I
> think that will provide the easiest way to understand this.
>
> Thank you,
>
> Bob
>
> On 10/20/06, Ruslan Sivak <rsivak@istandfor.com> wrote:
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 23 23:40:30 2006