corrupted text-base files not being detected and/or repaired

Hi! I'm writing directly to the dev-list because I think that this is
a rather serious problem, and I have already looked in the issue
tracker, and found that it has been discussed before but been neglected.

We just had a situation which caused some of our developers to start
wondering whether they can really trust Subversion at all. One of our
lead developers had been preparing an internal release, doing some
tagging and switching, and somehow his working copy got broken: one
text-base file was not up to date with respect to the repository version
that it claimed to be. But everything seemed just dandy, so he created a
release package and published it. It was soon discovered that there was
a fatal error in the package, and he tracked down the out-of-sync file.

Now, it might well be that by using a different workflow, he could have
avoided shipping a broken package, but that is not the point here. The
main issue is that *none of the svn commands would report that the
working copy was broken*, and there is no way (not 'svn cleanup', no
flag to 'svn update', or anything) that can automatically replace broken
text-base files even when you have manually detected the problem.

I found the following issue report:

   http://subversion.tigris.org/issues/show_bug.cgi?id=793

which discusses a possible 'svn repair' command for fixing text-base
files, but it was closed and marked as a duplicate of issue 689. I think
this was a mistake, because it seems that the actual issue about fixing
(and detecting and reporting) broken text-base files was then lost in
the discussion about checksums:

   http://subversion.tigris.org/issues/show_bug.cgi?id=689

There is also this report about 'svn revert' not verifying checksums:

   http://subversion.tigris.org/issues/show_bug.cgi?id=1774

that had a tentative fix, but which was removed again due to performance
problems. A question from that issue report was: 'Why on earth do we
*care*? Our usual policy is "Mess with .svn and bad things will happen".
Why are we deviating in this case?' - well, you *should* care because it
is typically not the user who has messed with the .svn directory; like
as not, it was corrupted because of some svn command that did not
complete its execution properly.

Here's an old mailing list discussion about the same thing:
   http://svn.haxx.se/dev/archive-2003-01/0997.shtml

I think that the least one should be able to depend on is that commands
like svn ci, svn cleanup, svn update, or svn st -u, should check that
the text-base file has the right checksum, and report any problems.
Preferably, they should also fix the problem by downloading a new copy.
(I see no need for a separate 'svn repair' command.)

So, *please*, do something about this. The issue reports above have been
around for up to five years, and the problem is still just as bad as it
was in 2002. (It is easily reproducible by manually changing a text-base
file and trying to see if anything will detect/fix it.)

I don't really have any other gripes with Subversion - it's a great
tool, and a vast improvement on what we used to have, but we need to be
able to trust it when it says that our working copy looks OK.

     /Richard Carlsson

-- 
// ---------------------------------------------------------------------
Richard Carlsson <Richard.Carlsson@iar.se>                IAR Systems AB
Software Developer                                     http://www.iar.se
  -------------------------------------------------------------------- //
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org