Erik Huelsmann <ehuels@gmail.com> writes:
> 'svn merge' and 'svn diff' share the same implementation for receiving
> added files from the repository, which uses
> libsvn_client/repos_diff.c:create_empty_file().
>
> The create_empty_file() routine prefers the cwd to create its
> temporaries in. Which is fine for diff (probably), but is a problem
> for merge if the cwd is on a different device than the target working
> copy.
>
> The diff-editor doesn't know whether it's driving a merge or a diff,
> meaning that there is no way to keep the old behaviour for diff and
> the new one for merge. Is it acceptable for diff to start requiring
> write access to the .svn/tmp areas in order to solve the problem with
> merge?
>
> I used this scenario to find the problem:
>
> - mount a RAM disk at subversion/tests/clients/cmdline/svn-test-work
> - build the wc-replacements branch sources (in-tree)
> - run the tests from the root of your working copy
>
> These tests should FAIL:
> * merge_tests.py 26: merge a replacement of a file
> * revert_tests.py 5: revert a merged replacement of a file with history
Isn't this what http://subversion.tigris.org/issues/show_bug.cgi?id=767
is about? (You've commented extensively in that issue, actually.)
My comment http://subversion.tigris.org/issues/show_bug.cgi?id=767#desc20
describes a possible solution -- or rather, incompletely describes a
solution that I'll try to state more fully here:
Use apr_temp_dir() to get a temp directory, since using the cwd is
obviously insane. Then, implement a more robust version of
svn_io_file_rename() -- either enhance the existing one, or make a
new API -- that tries to rename, but if it fails due to some
non-fatal problem like a cross-device rename, then it falls back to
an O(N) copy to do the rename.
I guess as an intermediate step, we could try CWD/.svn/tmp before
falling back to O(N) copy, but that feels a bit unclean to me.
Thoughts?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 26 22:07:45 2005