Use svn cat_at_BASE to get the file.
File is moved to revertbase to allow replacement with history.
Bert (mobile phone)
----- Oorspronkelijk bericht -----
Van: Neels J Hofmeyr <neels_at_elego.de>
Verzonden: zaterdag 16 januari 2010 23:48
Onderwerp: libsvn_wc bug: pristine contents for locally replaced file
is there a good reason why a local replace has to get rid of the pristine
base file? Because, if the file was kept, the problems described below would
I stumbled over an error using 'svn cat <wc_path>' on a locally replaced
file. (Not a common use case, but read on.) 'svn cat <wc_path>' appears to
want to output the pristine base content (which is not documented).
But when a file is locally replaced (not committed), it currently has no
pristine base file, apparently;
'svn cat wc/locally_replaced_file'
which errors with:
$ svn cat file
svn: Can't open file '/tmp/wc/.svn/text-base/file.svn-base': No such file or
(reproduction script attached)
'svn cat' is just an example of how to hit this. This same function is used
in many other places. A quick impact grep study suggests at least export,
copy, update, diff, and probably others.
(Todo: investigation on whether current callers can hit a locally replaced
file and whether they work around it.)
I guess svn_wc__get_pristine_contents() wants to return the contents of the
file that were committed in revision <BASE>. But the implementation expects
a file to exist which isn't there:
const char *local_abspath,
const char *text_base;
SVN_ERR(svn_wc__text_base_path(&text_base, db, local_abspath, FALSE,
if (text_base == NULL)
*contents = NULL;
return svn_stream_open_readonly(contents, text_base, result_pool,
// ^^^^^ hits error here, file *text_base does not exist.
I see two ill things:
(1) Looking at the function's intention, it should return an empty stream if
there is no base file. But svn_wc__text_base_path() returns a path that
(2) When the file is locally replaced, it theoretically *does* have a
pristine base, i.e. the file's content committed at revision <BASE>. The
function fails to return that content.
So, back to the question: is there a good reason why a local delete followed
by a local add has to get rid of the pristine base file?
Received on 2010-01-17 09:51:08 CET