[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge conflicts files that weren't modified

From: Mark Phippard <markphip_at_gmail.com>
Date: 2006-12-19 22:34:20 CET

On 12/19/06, Denny Caldwell <dcaldwell@grinn.net> wrote:
>
> (I'm pretty sure I had already posted this once, but it's been out there
> for a while and I still haven't had a response.)
>
> The software we develop can be highly customized at our client's request.
> We're attempting to use svn to allow us to maintain these customizations for
> our clients, and also allow us to push updates and bug fixes committed to
> our trunk system to these client's individual branches.
>
> Let me precept my issue with my understanding of what a merge is. From
> what I understood, if you have two branches and you modify them both, a
> merge is meant to allow you to copy the changes from branch A to branch B
> without overwriting the changes in branch B. Additionally, this only merges
> the files that were modified in branch A to branch B and only has a conflict
> if the same line in the same file was modified in both branches A and B
> during the selected revisions.
>
> Here's my scenario. This is all using Tortoise, mind you:
>
> /branches/client1 created from trunk rev 5
> /trunk modified 30 files, rev 7
>
> merge:
> from url: /trunk, rev: 5
> to url: /trunk, rev: HEAD
> destination: /branches/client1
> (no conflicts, all goes well, 30 files modified.)
>
> /branches/client1 modified 5 files, rev 9
> /trunk modified 50 files, rev 10
>
> merge:
> from url: /trunk, rev: 5
> to url: /trunk, rev: HEAD
> destination: /branches/client1
>
> I get conflicts on 12 files, most of them which were not even modified in
> client1 since the last merge!
>
> I can only guess that it's because those files were modified during the
> *previous* merge, in rev 8. If this is the case, how can I sell svn, "Hey! I
> only need to keep the revisions I've made to the destination since my last
> merge."?

Yes that is the problem. It is the "Repeated Merge problem". See this
section of the book:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac

There is a merge tracking feature being worked on that would eliminate the
need for some of this. You can get some of it today by using the
svnmerge.py script that is in the SVN repository. Personally, I have found
that once you know what you need to do it is not too hard to manage and
track.

Mark
Received on Tue Dec 19 22:35:01 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.