You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Aldrich <Da...@EMEA.NEC.COM> on 2012/09/19 09:15:40 UTC

Merging headache

Hi

I am trying to update a branch with changes from the trunk. I am getting tree conflicts that I do not know how to resolve. Please will someone take a look at my console output below and advise me what to do? (For the sake of security, I have sanitised the folder names).

BR

David

C:\SVNProj\MyProj​branches\TRY_MyBra​nch_23Jan2012>svn​ merge ^^/trunk
Conflict discovered in 'C:/SVNProj/MyProj/b​ranches/TRY_MyBranch​_23Jan2012/Simulatio​ns/MyFolder/file1.xl​sx'.
Select: (p) postpone,
(mf) mine-full, (tf) theirs-full,
(s) show all options: mf
--- Merging r4283 into 'Simulations':
U Simulations\MyFolder\file1.xlsx
C Simulations\MyFolder\file2.xml
C Simulations\MyFolder\file3.xlsx
C Simulations\MyFolder\file4.xml
Conflict for property 'svn:mergeinfo' discovered on 'C:/SVNProj/MyProj/b​ranches/TRY_MyBranch​_23Jan2012/Simulatio​ns'.
They want to delete the property, you want to change the value to '/branches/TRY_DRA_P​ython_14July10/Simul​ations:2616-27
48
/branches/TRY_DRA_Sy​stemC_2_2_19April201​1/Simulations:3375-3​405
/branches/TRY_DRA_ti​nyxml2_6_1_7Oct2010/​Simulations:2919-292​5
<some other branches listed here>
/trunk/Simulations:4113-4181'.
Select: (p) postpone,
(mf) mine-full, (tf) theirs-full,
(s) show all options: mf
U Simulations
--- Recording mergeinfo for merge of r4113 through r4283 into '.':
U .
Summary of conflicts:
Tree conflicts: 3
svn: E155015: One or more conflicts were produced while merging r4282:4283 into
'C:\SVNProj\MyProj​\branches\TRY_MyBr​anch_23Jan2012' --
resolve all conflicts and rerun the merge to apply the remaining
unmerged revisions

RE: Merging headache

Posted by John Maher <Jo...@rotair.com>.
Don't know if this will help you or not, but I ran into some problems
(still am) learning subversion.  I can tell you what I learned.

Someone told me that conflicts are normal, and when I looked deeper,
they are 100% correct.  The merge doesn't work perfect all the time.  It
depends on your changes.

For example, I deleted a function and created a new one in its place.
During a merge this caused a conflict.  There was different code in the
same place in the source and the target.  Which to keep?  This SHOULD
cause a conflict so a human can look and choose the right one.  That is
why they say merge often, less changes means less chance for a conflict.
But conflicts will occur.

One way to fix things is to make a new repository.  You lose all your
history so it would depend on how long you've been using subversion and
how important your history is vs how bad your current repository is.  A
new repository will start you with a clean slate and you keep the old
one for the history.  You then need to be more careful.

Another way to fix things is to manually fix all the conflicts.
Subversion does a lot of things and some of them are not so straight
forward.  But it is also very powerful.  Very easy to shoot yourself in
the foot.

John

-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de] 
Sent: Wednesday, September 19, 2012 4:34 AM
To: David Aldrich
Cc: users@subversion.apache.org
Subject: Re: Merging headache

On Wed, Sep 19, 2012 at 08:19:59AM +0000, David Aldrich wrote:
> As this is rather a mess, can you suggest a way to get back to some
degree of order?

I'm afraid I cannot make any reasonable suggestion at this point, sorry.
I'd need more information about what really happened.

Re: Merging headache

Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 08:19:59AM +0000, David Aldrich wrote:
> As this is rather a mess, can you suggest a way to get back to some degree of order?

I'm afraid I cannot make any reasonable suggestion at this point, sorry.
I'd need more information about what really happened.

RE: Merging headache

Posted by David Aldrich <Da...@EMEA.NEC.COM>.
Hi Stefan

Thanks very much for your advice, I will take careful note of it.

> BTW, I'm curious why you're getting an svn:mergeinfo conflict.
> That should never happen if you follow best practices.
> Is this common in your environment? If so, it seems people must be doing
> something quite wrong, but I don't really know what it could be. Are people
> editing mergeinfo by hand or gratuitously deleting it?

I really don't know why this has happened.  AFAIK we never edit mergeinfo by hand.

As this is rather a mess, can you suggest a way to get back to some degree of order?

BR

David

Re: Merging headache

Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 07:15:40AM +0000, David Aldrich wrote:
> Hi
> 
> I am trying to update a branch with changes from the trunk. I am getting tree conflicts that I do not know how to resolve. Please will someone take a look at my console output below and advise me what to do? (For the sake of security, I have sanitised the folder names).
> 

Hi David,

Generally, to deal with tree conflicts, you need to:

 1) Find out why it happened: Check 'svn log -v' output for
    changes to affected paths that others committed, and think
    about how these would conflict with your own changes; and/or
    talk to the people who made those changes to figure out where
    your collective actions might conflict from the point of
    view of svn.

 2) Figure out what you really want the merge result to be.
    What's the state you want your branch to be in? Keep in mind
    that if you're planning on merging the branch back to trunk,
    the decisions you make here will ultimately affect trunk and
    other branches, too. I.e. don't just make life easy for yourself
    by reverting other peoples' changes without reason :)

 3) Figure out how to get the conflicted working copy into the
    desired state you determined in step 2), by using only svn
    commands and editing files (you can use 'svn merge' to merge
    into files, if that helps!).
    Here you may need to be creative, and this is where we can help.
    However, people on this list will not be able to help you much
    with 1) and 2) because we lack the necessary context to give
    advice on what decisions need to be made.

When you describe conflicts to us, please also show the output of
'svn status' and 'svn info' for affected file. These commands show
additional information about conflicts.
>From what you've posted so far, all we can tell is that there are
conflicts, but we cannot help you any further without more
information about the nature of these conflicts.

BTW, I'm curious why you're getting an svn:mergeinfo conflict.
That should never happen if you follow best practices.
Is this common in your environment? If so, it seems people must
be doing something quite wrong, but I don't really know what it
could be. Are people editing mergeinfo by hand or gratuitously
deleting it?

> C:\SVNProj\MyProj​branches\TRY_MyBra​nch_23Jan2012>svn​ merge ^^/trunk
> Conflict discovered in 'C:/SVNProj/MyProj/b​ranches/TRY_MyBranch​_23Jan2012/Simulatio​ns/MyFolder/file1.xl​sx'.
> Select: (p) postpone,
> (mf) mine-full, (tf) theirs-full,
> (s) show all options: mf
> --- Merging r4283 into 'Simulations':
> U Simulations\MyFolder\file1.xlsx
> C Simulations\MyFolder\file2.xml
> C Simulations\MyFolder\file3.xlsx
> C Simulations\MyFolder\file4.xml
> Conflict for property 'svn:mergeinfo' discovered on 'C:/SVNProj/MyProj/b​ranches/TRY_MyBranch​_23Jan2012/Simulatio​ns'.
> They want to delete the property, you want to change the value to '/branches/TRY_DRA_P​ython_14July10/Simul​ations:2616-27
> 48
> /branches/TRY_DRA_Sy​stemC_2_2_19April201​1/Simulations:3375-3​405
> /branches/TRY_DRA_ti​nyxml2_6_1_7Oct2010/​Simulations:2919-292​5
> <some other branches listed here>
> /trunk/Simulations:4113-4181'.
> Select: (p) postpone,
> (mf) mine-full, (tf) theirs-full,
> (s) show all options: mf
> U Simulations
> --- Recording mergeinfo for merge of r4113 through r4283 into '.':
> U .
> Summary of conflicts:
> Tree conflicts: 3
> svn: E155015: One or more conflicts were produced while merging r4282:4283 into
> 'C:\SVNProj\MyProj​\branches\TRY_MyBr​anch_23Jan2012' --
> resolve all conflicts and rerun the merge to apply the remaining
> unmerged revisions