-bytes branch reports bogus conflict that trunk doesn't
Johan,
I saw your sync merge, so I ran 'svn up' with intent to rebuild. When
I ran that 'up' with the branch build, I got a conflict, which didn't
appear when I ran it with a trunk build. (See attached transcript.)
Furthermore, the conflict resolution (a) marked all the head of the file
as conflict (which is wrong; line 49 did change, but the first
20-something lines are identical), and (b) deleted everything after
line 232.
I realize that (a) is an outstanding issue (discussed in another thread
this weekend), but I don't recall that (b) is a known issue.
Daniel
% pwd
/home/daniel/src/svn/bytes
% .svn
/home/daniel/src/svn/bytes
% $svnversion
1054012M
% $svn st -q
M subversion/libsvn_diff/diff_memory.c
M subversion/libsvn_diff/diff3.c
% $svn di
Index: subversion/libsvn_diff/diff_memory.c
===
--- subversion/libsvn_diff/diff_memory.c(revision 1054012)
+++ subversion/libsvn_diff/diff_memory.c(working copy)
@@ -104,6 +104,7 @@
{
/* Do nothing: everything is already there and initialized to 0 */
return SVN_NO_ERROR;
+ /* ### */
}
Index: subversion/libsvn_diff/diff3.c
===
--- subversion/libsvn_diff/diff3.c (revision 1054012)
+++ subversion/libsvn_diff/diff3.c (working copy)
@@ -243,18 +243,25 @@
}
+static int hit = 1;
+
svn_error_t *
svn_diff_diff3(svn_diff_t **diff,
void *diff_baton,
const svn_diff_fns_t *vtable,
apr_pool_t *pool)
{
+ svn_diff_datasource_e datasource[] = {svn_diff_datasource_original,
+svn_diff_datasource_modified,
+svn_diff_datasource_latest};
svn_diff__tree_t *tree;
svn_diff__position_t *position_list[3];
svn_diff__lcs_t *lcs_om;
svn_diff__lcs_t *lcs_ol;
+ apr_off_t prefix_lines;
apr_pool_t *subpool;
apr_pool_t *treepool;
+ hit++;
*diff = NULL;
@@ -263,28 +270,33 @@
svn_diff__tree_create(tree, treepool);
+ SVN_ERR(vtable-datasources_open(diff_baton, prefix_lines, datasource, 3));
+#if 0
+ SVN_DBG((prefix_lines = % APR_OFF_T_FMT \n, prefix_lines));
+#endif
+
SVN_ERR(svn_diff__get_tokens(position_list[0],
tree,
diff_baton, vtable,
svn_diff_datasource_original,
- FALSE,
- 0,
+ TRUE,
+ prefix_lines,
subpool));
SVN_ERR(svn_diff__get_tokens(position_list[1],
tree,
diff_baton, vtable,
svn_diff_datasource_modified,
- FALSE,
- 0,
+ TRUE,
+ prefix_lines,
subpool));
SVN_ERR(svn_diff__get_tokens(position_list[2],
tree,
diff_baton, vtable,
svn_diff_datasource_latest,
- FALSE,
- 0,
+ TRUE,
+ prefix_lines,
subpool));
/* Get rid of the tokens, we don't need them to calc the diff */
% $svn up --accept postpone -q
% $svn st -q
C subversion/libsvn_diff/diff_memory.c
M subversion/libsvn_diff/diff3.c
% $svn di su*/*ff/*memory.c
Index: subversion/libsvn_diff/diff_memory.c
===
--- subversion/libsvn_diff/diff_memory.c(revision 1054447)
+++ subversion/libsvn_diff/diff_memory.c(working copy)
@@ -1,3 +1,4 @@
+ .mine
/*
* diff_memory.c : routines for doing diffs on in-memory data
*
@@ -34,7 +35,45 @@
#include svn_utf.h
#include diff.h
#include svn_private_config.h
+===
+/*
+ * diff_memory.c : routines for doing diffs on in-memory data
+ *
+ *
+ *Licensed to the Apache Software Foundation (ASF) under one
+ *or more contributor license agreements. See the NOTICE file
+ *distributed with this work for additional information
+ *regarding copyright ownership. The ASF licenses this file
+ *to you under the Apache License, Version 2.0 (the
+ *License); you may not use this file except in compliance
+ *with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *Unless required by applicable law or agreed to in writing,
+ *software distributed under the License is distributed on an
+ *AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ *KIND, either
Re: -bytes branch reports bogus conflict that trunk doesn't
On Sun, Jan 2, 2011 at 7:36 PM, Daniel Shahaf danie...@apache.org wrote: Johan, I saw your sync merge, so I ran 'svn up' with intent to rebuild. When I ran that 'up' with the branch build, I got a conflict, which didn't appear when I ran it with a trunk build. (See attached transcript.) Did you do that with a build of HEAD of diff-optimizations-bytes (i.e. only changes to diff2 behavior)? Or with a build where the patch for diff3 was applied? Johan Furthermore, the conflict resolution (a) marked all the head of the file as conflict (which is wrong; line 49 did change, but the first 20-something lines are identical), and (b) deleted everything after line 232. I realize that (a) is an outstanding issue (discussed in another thread this weekend), but I don't recall that (b) is a known issue. Daniel
Re: -bytes branch reports bogus conflict that trunk doesn't
Johan Corveleyn wrote on Sun, Jan 02, 2011 at 20:13:59 +0100: On Sun, Jan 2, 2011 at 7:36 PM, Daniel Shahaf danie...@apache.org wrote: Johan, I saw your sync merge, so I ran 'svn up' with intent to rebuild. When I ran that 'up' with the branch build, I got a conflict, which didn't appear when I ran it with a trunk build. (See attached transcript.) Did you do that with a build of HEAD of diff-optimizations-bytes (i.e. only changes to diff2 behavior)? Or with a build where the patch for diff3 was applied? The latter, I believe. Johan Furthermore, the conflict resolution (a) marked all the head of the file as conflict (which is wrong; line 49 did change, but the first 20-something lines are identical), and (b) deleted everything after line 232. I realize that (a) is an outstanding issue (discussed in another thread this weekend), but I don't recall that (b) is a known issue. Daniel
Re: -bytes branch reports bogus conflict that trunk doesn't
On Sun, Jan 2, 2011 at 8:19 PM, Daniel Shahaf danie...@apache.org wrote: Johan Corveleyn wrote on Sun, Jan 02, 2011 at 20:13:59 +0100: On Sun, Jan 2, 2011 at 7:36 PM, Daniel Shahaf danie...@apache.org wrote: Johan, I saw your sync merge, so I ran 'svn up' with intent to rebuild. When I ran that 'up' with the branch build, I got a conflict, which didn't appear when I ran it with a trunk build. (See attached transcript.) Did you do that with a build of HEAD of diff-optimizations-bytes (i.e. only changes to diff2 behavior)? Or with a build where the patch for diff3 was applied? The latter, I believe. Phew, that's a relief :-). I'm pretty confident of the diff2 changes that are currently committed, but the diff3 patch posted yesterday is definitely broken. Interesting info, none the less, to see how it's broken, so thanks. I'll see if this helps me understand where it's going wrong ... Johan Furthermore, the conflict resolution (a) marked all the head of the file as conflict (which is wrong; line 49 did change, but the first 20-something lines are identical), and (b) deleted everything after line 232. I realize that (a) is an outstanding issue (discussed in another thread this weekend), but I don't recall that (b) is a known issue. Daniel
Re: -bytes branch reports bogus conflict that trunk doesn't
Johan Corveleyn wrote on Sun, Jan 02, 2011 at 20:45:02 +0100: On Sun, Jan 2, 2011 at 8:19 PM, Daniel Shahaf danie...@apache.org wrote: Johan Corveleyn wrote on Sun, Jan 02, 2011 at 20:13:59 +0100: On Sun, Jan 2, 2011 at 7:36 PM, Daniel Shahaf danie...@apache.org wrote: Johan, I saw your sync merge, so I ran 'svn up' with intent to rebuild. When I ran that 'up' with the branch build, I got a conflict, which didn't appear when I ran it with a trunk build. (See attached transcript.) Did you do that with a build of HEAD of diff-optimizations-bytes (i.e. only changes to diff2 behavior)? Or with a build where the patch for diff3 was applied? The latter, I believe. Phew, that's a relief :-). I'm pretty confident of the diff2 changes that are currently committed, but the diff3 patch posted yesterday is definitely broken. I didn't use the patch you posted. I believe I used the patch reproduced within the transcript. Interesting info, none the less, to see how it's broken, so thanks. I'll see if this helps me understand where it's going wrong ... Happy digging :-) Daniel Johan Furthermore, the conflict resolution (a) marked all the head of the file as conflict (which is wrong; line 49 did change, but the first 20-something lines are identical), and (b) deleted everything after line 232. I realize that (a) is an outstanding issue (discussed in another thread this weekend), but I don't recall that (b) is a known issue. Daniel
