Hi All,
Further investigation revealed, in my opinion, the strange behaviour is
an outcome of resolving bug 2403 and/or 1319
The issues below, explains the behaviour (I experienced) during svn
merge of binary files with ancestry. ie the merge screen displays that
the binary file was ** Updated **. But there is ** NO ** change in the
Working Copy and nothing to commit.
Could the more experienced users please advise me if this should be
raised as an issue.
http://subversion.tigris.org/issues/show_bug.cgi?id=2403
Below is an extract from the log for bug 2403.
/* Special case: if a binary file isn't locally modified, and is
exactly identical to the 'left' side of the merge, then don't
allow svn_wc_merge to produce a conflict. Instead, just
overwrite the working file with the 'right' side of the merge.
*/
http://subversion.tigris.org/issues/show_bug.cgi?id=1319
Thanks
Lakshman
-----Original Message-----
From: Srilakshmanan, Lakshman
[mailto:lakshman.srilakshmanan_at_police.vic.gov.au]
Sent: Thursday, 11 June 2009 2:37 PM
To: users_at_subversion.tigris.org
Subject: Merging binary files with ancestry
Hi All,
I submitted this post to the user forum on Friday 5/6/2009 but can't
find it :(
I have searched svn mailing list and goggled for an answer all day. I
will be grateful to anyone who can answer my question and put me out of
my misery as a logical explanation is eluding me and driving me insane.
Any help in this is greatly appreciated.
I came across an interesting issue while performing a merge on binary
files with and without using ancestry.
I am currently using svn 1.4.6
Step 0. Create a branch (MergeTest2) from trunk (note : trunk should
contain a binary file) (r29) Step 1. modify a binary file in trunk. (ie
copy another binary file on top of an existing file) and commit it (r30)
Step 2. merge trunk into branch and commit http://host/svn/sgs/trunk
r29:30 (r31)
Step 3. merge branch into trunk. http://host/svn/sgs/trunk
http://host/svn/sgs/branch/MergeTest2
Step 3 will display that the binary file was ** Updated **. But there is
** NO ** change in the Working Copy.
If you perform Step 3 with --ignore-ancestry then there is ** nothing **
on the display and no change in the Working Copy either. (what I would
expect).
My question is why would the --ignore-ancestry flag cause a difference
in merge display when there is ** NO change ** in the ancestry to start
with.
svn log the binary file in branch "MergeTest2" shows the following Note
: r25 & r27 are from trunk ** before ** creating the MergeTest2 branch.
This proves that svn is maintaining the ancestry relationship.
------------------------------------------------------------------------
r31 | UsrID | 2009-06-05 17:12:09 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
M /branch/MergeTest2/BIN.exe
received update from trunk at rev30
------------------------------------------------------------------------
r29 | UsrID | 2009-06-05 17:07:41 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
A /branch/MergeTest2 (from /trunk:28)
Copied remotely
------------------------------------------------------------------------
r27 | UsrID | 2009-06-05 16:54:45 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
M /trunk/BIN.exe
Modified file
------------------------------------------------------------------------
r25 | UsrID | 2009-06-05 16:50:01 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
A /trunk/BIN.exe
Test for merging binary files
------------------------------------------------------------------------
Thanks
Lakshman
========================================================================
========================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be
subject to copyright.
If you are not an intended recipient of this email please immediately
contact us by replying to this email and then delete this email.
You must not read, use, copy, retain, forward or disclose this email or
any attachment.
We do not accept any liability arising from or in connection with
unauthorised use or disclosure of the information contained in this
email or any attachment.
We make reasonable efforts to protect against computer viruses but we do
not accept liability for any liability, loss or damage caused by any
computer virus contained in this email.
========================================================================
========================
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2361162
To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367236
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-02 03:44:09 CEST