Russ,
Sorry if I wasn't clear. I asked for the actual command because the
example you provided doesn't make much sense as a real case. My point
is that I suspect that when you merge from the branch to the trunk,
you use as the two comparison points the beginning of the branch and
the head of the branch, when you clearly know that you have already
updated from the trunk to the branch and would therefore be
double-merging.
While the textual double-merge is caught by SVN, that is because
this is a contrived example. In a more realistic case, the text could
be changed on the branch after the merge from the trunk. For this
reason, you have to be very careful when performing such bidirectional
merges.
I think to limit your errors, you should stick to one process.
Either don't update the branch with changes from the trunk, or *fully*
update the branch from the trunk just prior to the reverse merge.
If you follow the first rule, you don't have your original problem.
If you follow the second rule, you change the merge from the branch to
the trunk to comparing the trunk HEAD and the branch HEAD, instead of
the branch root and branch HEAD.
On 10/23/06, Ruslan Sivak <rsivak@istandfor.com> wrote:
> 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:51:15 2006