> 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
> 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
It really depends on what type of branch it is. For a feature branch or developer branch you want to contantly merge from trunk to branch to keep your branch up to do to ensure your changes aren't conflicting with what is happening on trunk.
If you are doing release branches and fixing issues on that release branch that you want to move back to trunk, then you would merge from branch back to trunk. Perhaps this is your branching strategy.
Or perhaps you weren't aware of the new reintegration merge that was added in 1.5 and are just doing traditional two tree merges from a feature branch back to trunk.
We use both feature branches and release branches. However, we don't use a single "trunk" since we found it too cumbersome and also had some other issue since our build scripts rely on file dates.
BOb
Received on 2011-12-09 16:07:11 CET