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

Merge bug(let)

From: Sander Striker <striker_at_apache.org>
Date: 2003-02-26 13:22:20 CET

> From: Philip Martin
> Sent: Tuesday, February 25, 2003 9:03 PM

> "Sander Striker" <striker@apache.org> writes:
>
>> Upon investigation of subversion/libsvn_wc/merge.c I saw that we are
>> trying to merge 3 conflicting files and then we leave 3 non
>> conflicting files in the wc. The reason the 3 files we try to merge
>> conflict is because we aren't doing eol translation prior to running
>> merge (is my guess). We are doing that _after_ we see the conflict.
>
> Yes, at present merge occurs using all three files in
> repository-normal form, which involves translating the working copy
> file to repository-normal form before merging.

Well, something is definately not working right, since I would expect
a clean merge when all files are in repos normal form.

This patch confirms my suspicion and shows that diff3 behaves the
same way as the internal merge code (it leaves the files that
were used to do the merge instead of translated ones):

Index: subversion/libsvn_wc/merge.c
===================================================================
--- subversion/libsvn_wc/merge.c (revision 5076)
+++ subversion/libsvn_wc/merge.c (working copy)
@@ -273,6 +273,7 @@
                                          NULL, pool));
           SVN_ERR (svn_wc__get_eol_style (NULL, &eol, merge_target, adm_access,
                                           pool));
+#if 0
           SVN_ERR (svn_subst_copy_and_translate (left,
                                                  left_copy,
                                                  eol, eol ? TRUE : FALSE,
@@ -286,6 +287,12 @@
           SVN_ERR (svn_io_copy_file (merge_target,
                                      target_copy, TRUE, pool));

+#else
+ SVN_ERR (svn_io_copy_file (left, left_copy, TRUE, pool));
+ SVN_ERR (svn_io_copy_file (right, right_copy, TRUE, pool));
+ SVN_ERR (svn_io_copy_file (tmp_target, target_copy, TRUE, pool));
+#endif
+
           /* Derive the basenames of the 3 backup files. */
           svn_path_split (left_copy, NULL, &left_base, pool);
           svn_path_split (right_copy, NULL, &right_base, pool);

After applying that, use the repro recipe:

$ svn co http://svn.collab.net/repos/svn/branches/0.18.1/build/win32
$ cd win32
$ svn merge -r 5007:5008 http://svn.collab.net/repos/svn/trunk/build/win32
$ diff3 -m -E build_neon.bat.working build_neon.bat.merge-left.r5007 build_neon.bat.merge-right.r5008
[output shows conflicts]

>> My take is that we need to do it before (but not the keyword
>> expansion).
>>
>> Thoughts? Better insights?
>
> Interesting idea. Would it mean that the merge might behave
> differently on different platforms?

It doesn't really matter if you merge files with CRLF or LF endings,
as long as it is consistent. I don't think the outcome of the
merge would be any different.

> I don't suppose that's really a problem, even if it does happen.

My thoughts exactly.

> Note that the three files could each have svn:eol-style set to a
> different value.

Hmpf, yes, that would be a problem.

> Would you use the the setting appropriate for each
> file or would you pick one, the working copy most probably, and use
> that for all the files?

And that sounds like a viable solution ;)
Thanks,

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 26 13:23:19 2003

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

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