Bob,
I don't think one process will work for us. Sometimes it is necessary
to merge from trunk mid way when working on a branch, just so that you
have all the latest code, as sometimes the code is very intertwined.
Lets say someone added a library to the trunk that I would like to use
in my branch. I'm not modifying the library, just using it, and when I
later merge the branch back from the trunk, I would like the library
file not to conflict (which it won't, the way subversion works now).
Now imagine the library is a dll that was added instead of a piece of
code. Now when I merge it back to the trunk, it will conflict.
If this isn't a bug in subversion, maybe I'm doing it wrong. Should I,
after merging from the trunk into the branch, update my tag? I create a
tag called pre-BranchName in the tags folder, which is a copy of the
trunk right before the branch is created. Should I update that when I
merge from the trunk, so that when I do a subsequent merge it will only
do the changes that happened past that point?
Russ
Bob Hiestand wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 24 00:39:55 2006