On Thu, Jul 26, 2012 at 11:53:16AM +0200, Kiren Pillay wrote:
> Hi
>
> I have an additional question:
>
> It looks like the latest version of both branches have exactly the same. It
> looks like the conflict occured in a revision that has been merged a while
> back in its history ( svn://bcx-svn/
> vodacom.za/pams/server/branches/V1-1-1-preprod/business_services/main_servlet/src/main/resources/testconfigs/pams.properties_at_6896)
> . Is there any reason for this?
>
Hard to say without direct access to the 'svn log' output.
Try running 'svn log -v' on the merge commits. If a file was newly
added rather than modified, it shows up as:
A myfile
rather than:
M myfile
Or you might see:
R myfile
which means replaced (deleted and added in the same revision).
Since an addition or deletion is an explicit operation in Subversion
it will also be merged as such. This can get ugly in case somebody
accidentally replaces a file. E.g. suppose rather than using 'svn revert'
to undo edits, somebody naively runs 'svn delete' on the modified file
followed by 'svn add' to re-add the pristine version of the file,
and commits this change.
If you then keep merging to and fro between two branches and never fold
the 'add' (or 'replace') operation into a normal 'modification' operation,
the merges will keep flagging 'add vs. add' tree conflicts. Each merge
will try to add the object again since the addition is part of the
changeset being merge. An addition is supposed to create a new object,
either on top of a non-conflicted deleted object or at a path where no
object exists. Anything else is flagged as a conflict.
To fold an 'add' into a 'modify', revert the affected path after the
merge and then merge file content from the other branch either manually
or via a --ignore-ancestry merge. E.g. if merging from trunk to a
branch try something like:
svn merge ^/trunk
C myfile
> add vs. add conflict
svn revert myfile # undo add vs. add conflict
svn merge --ignore-ancestry ^/trunk/myfile myfile
More information about what --ignore-ancestry can be found at
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry
> I suspect its because we haven't been doing reintegrate merges until
> recently?
That is quite possible. A non-reintegrate merge can produce a delta
with different semantics and might produce an addition or replace
where a reintegrate merge would just produce a modified file.
Users often don't understand this or feel they shouldn't have to,
and a missing --reintegrate option can sometimes cause merge problems
even for later merges.
BTW, steps are being taken to make the --reintegrate option unnecessary
in Subversion 1.8, so this user interface problem will hopefully be
fixed by then.
> Is there a way to stop this from happening in future?
Yes. Follow the best practices described in this chapter of the svnbook:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html
A short summary that every user performing merges should know is
provided in the output of 'svn help merge' in Subversion 1.7, also
available at: http://subversion.apache.org/docs/svn-merge.txt
Received on 2012-07-26 15:55:45 CEST