Re: Question

Let me explain my reasoning.

My thinking is that if you are trying to merge from trunk to branch, then
you are doing things the wrong way around, because if you copy out from
trunk, you merge back into trunk.

The other issue may be that If you copy from trunk more than once to the
same branch (from trunk) at different revisions, then try to merge back you
will likely get reflective merge issues. This is because SVN actually
tries to track the changes back. In this case you would need to do a
reintegrate merge. But from your explanation you are just doing copy, add
copy. Or have you actually copied more than once from trunk to the branch?
When you look at the merge conflicts, are they for for folders/files that
existed in trunk before the copy? If so they I really think you are doing
teh merge the wrong way around :)

I am therefore still concerned about your terminology of merging FROM trunk
INTO branch. It should most definitely be FROM branch INTO trunk. (excuse
the caps, I don't have the ability from here to make my text bold :) )

Rob

On 9 December 2011 12:44, Rob Pointer <rpointer_at_clearvision-cm.com> wrote:

> I have been looking through this thread and it might be resolved.
>
> Can I ask why you are trying to merge from trunk into the branch? The
> usual operation would be the other way around, otherwise you can run into
> reflective merge issues.
>
> Rob
>
>
> On 8 December 2011 18:10, Stefan Sperling <stsp_at_elego.de> wrote:
>
>> On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote:
>> > When I select merge a range of revisions and leave the range blank, it
>> says:
>> >
>> > Merging r7 through 42194
>> > <~10 tree conflicts on main folders>
>> >
>> > Does this mean we have never merged the trunk into the branch correctly
>> in
>> > a way that merge tracking recognizes, and how should I proceed to fix
>> the
>> > issue?
>>
>> It's possible that your server isn't new enough to support merge-tracking.
>> What version of Subversion is running on the server?
>> The minimum server version for merge-tracking is 1.5.
>> Your client should also at least be a 1.5 version and preferably 1.7.
>>
>> Another way this can happen is if you fail to commit the svn:mergeinfo
>> property the Subversion client creates during a merge.
>>
>> If you know the revision range you've already merged but failed to record
>> you can run the same merge as a 'record-only' merge. Tortoisesvn has a
>> checkbox for this in the merge dialog somewhere. A record-only merge will
>> create the svn:mergeinfo property but not actually merge any changes to
>> working files. Of course you must make sure that whatever revisions you
>> merge as record-only have already been merged. Else you're likely to
>> encounter more merging troubles down the road.
>>
>> BTW, the more common use case for record-only merges is to block revisions
>> you don't want to merge by marking them as already merged, see
>>
>> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges
>>
>
>
>
> --
> *Rob Pointer MSc*
> Software Specialist and Consultant
> rpointer_at_clearvision-cm.com <mmuschol_at_clearvision-cm.com>
>
> *
> Tel: +44 (0) 845 459 9530
> **
> **
> <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm>
> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news>
> <http://www.clearvision-cm.com/>
> *
>
>
>

-- 
*Rob Pointer MSc*
Software Specialist and Consultant
rpointer_at_clearvision-cm.com <mmuschol_at_clearvision-cm.com>
*
Tel: +44 (0) 845 459 9530
**
**
<http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm>
  <http://www.linkedin.com/company/clearvision>
<http://www.clearvision-cm.com/rss-feed/clearvision-news>
  <http://www.clearvision-cm.com/>
*