issue 1319 comes to light

Yesterday Karl and I found a pool bug in our merge code, but today I'm
discovering the true bug in issue 1319.

Basically, the bug is this:

  Run an 'svn merge' command which adds both a directory and a file
  inside the directory. If the file is binary, you end up with a
  (C)onflicted file.

Strange, eh?

Remember how merging works: the repository compares two revisions and
drives the repos-diff-editor in libsvn_client, which calls merge
callbacks to do the real work.

So what happens? I'll tell you. First the editor invokes
merge_dir_added(), which then runs svn_client_copy(URL, wc) to create
the new directory, scheduled for addition-with-history.

Then the editor invokes merge_file_added(). The function stats the
target. If the target doesn't exist, no problem, it does a
svn_client_copy(URL, wc). If the target does exist, it runs
svn_wc_merge().

Amazingly enough, the target *does* already exist -- and thus we get a
binary-file conflict. What? How can the target already exist?
Because we did a *recursive* URL->wc copy of the parent directory
already! Yikes!

This is absurd... and it's also issue 838. It's ridiculous that our
editor merge code is *ever* calling svn_client_copy(). It's an extra
RA session, and now we're seeing how the recursiveness is *redundant*
with the editor-drive that's already happening. Ugh.

So I think I need to pull issue 838 into pre-1.0, and mark 1319 as
dependent. Our merge code should be hand-creating the new directory/file
like a good little editor should, and then calling svn_wc_add() with
copyfrom args. No more redundancy, no more band-aids, no more lies!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 12 22:07:19 2003